I'm building a fast web crawler and I need to have multithreaded DNS resolution, so I picked up a multithreaded DNS service provider called dnsjava. Unfortunately, I can't figure out how to replace the default DNS Service Provider.
I went over the README file for dnsjava, but the instructions are not very through.
Replacing the standard Java DNS
functionality:
Beginning with Java 1.4, service
providers can be loaded at runtime.
To load the dnsjava service provider,
build it as explained above and set
the system property:
sun.net.spi.nameservice.provider.1=dns,dnsjava
This instructs the JVM to use the
dnsjava service provide for DNS at the
highest priority.
There are a couple of things that I'm unclear on:
Where do I place the dnsjava.jar?
Where is the system property supposed to be set (is it programmatic or some type of file change)?
I'm running on a Windows 7 machine and I'm not sure what I need to do to find/modify the system properties... help!?
Update:
Got it: System.setProperty("sun.net.spi.nameservice.provider.1","dns,dnsjava");
A wild guess.
Put the dnsjava.jar file in the classpath of your application.
Have the system property set before launching the main method in your application.
Related
I am running into the follow error while upgrading my versions of Jetty for a Dropwizard project:
java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory. (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
The tricky part is that I do not directly set up my SslContextFactory in code. Instead, Dropwizard sets it up behind the scenes at application startup, where it quickly runs into this issue and fails.
I see from the Dropwizard documentation that certain environment variables can be set on the Jetty server that it spins up, but I do not see documentation on how to modify specific classes.
If I add a jetty.xml file within $JETTY_HOME$/etc/config, will Dropwizard know how to pick this up?
I just need to understand how Dropwizard picks up settings on Jetty so I can use SslContextFactory.Server and resolve this error at startup.
Your version of Dropwizard is too old.
Dropwizard properly uses the SslContextFactory.Server where appropriate.
I've already spent more than 2 days trying to make this work without any result. The server is WebLogic 12c with embedded Coherence server. It is important to mention that I do not run Coherence in standalone mode, instead it starts automatically alongside the application server that has access to Coherence via JNDI context. I am trying to implement POF serialization approach using PortableObject interface to serialize certain objects I save in Coherence. I've also created the corresponding pof-config.xml registering the objects I'm planning to serialize. The only problem is: How do I add the override to the coherence class path?
According to http://docs.oracle.com/cd/E24290_01/coh.371/e22837/gs_config.htm#COHDG5014 I can use the following system property:
java -Dtangosol.pof.config=MyPOF.xml -cp COHERENCE_HOME;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer
The only problem here is that I have no idea which sh/cmd file to edit, since all edits I made to the files in Oracle_Home\coherence\bin\ had no effect.
Also the same article says that there is a way to confirm the pof-config override:
The output for a Coherence node indicates the location and name of the POF configuration deployment descriptors that are loaded at startup. The configuration messages are among the messages that display after the Coherence copyright text is emitted and are associated with the cache service that is configured to use POF. The output is especially helpful when developing and testing Coherence applications and solutions.
Loading POF configuration from resource "file:/D:/coherence/my-pof-config.xml"
But I couldn't find any of the mentioned lines in the logs produced by the server instance.
Any ideas?
Instead of editing files inside of your Oracle_Home, try the following inside of the weblogic admin console:
Login to admin console
Servers link -> Server Name
Click the Server Start tab
Edit the Arguments: text box and add in -Dtangosol.pof.config=MyPOF.xml
You can also change the classpath, Class Path: box, here if you need to
Every time your server starts it should have that property. If you are not using the nodemanager to start your server, you should do the following instead. Keep in mind this will change the properties for every server in your weblogic domain:
Navigate to your <domain home>/bin directory
Edit startWebLogic.sh/cmd
Edit the JAVA_OPTIONS= line and add in -Dtangosol.pof.config=MyPOF.xml
You can also change the classpath CLASSPATH= here if you need to
I am writing and small app using Java EE. I am using Apache Tomcat v 7 and Eclipse as IDE. When I Run the project (Run on server) I get :
http://127.0.0.1:8080/java-web/lis
(That's fine)
But I don't know If there is some way to rewrite the [java-web] dir just to get :
http://my-local-app.dev/list
I suppose there is some way like in Apache Server using confing files and enabling
the mod_rewrite.
I'll apreciate your help. Thanks
In short: All of the pieces you want to change are components of your deployment environment. Unless you have a specific need to override them, it's usually easiest during development to use the URLs that are a little less pretty.
If you do want to alter them, you need to familiarize yourself with what the various parts of an HTTP URL mean. What you have in your test environment is this:
http:// 127.0.0.1:8080/java-web/list
protocol host port path
You could insert an entry into your hosts file listing my-local-app.dev at 127.0.0.1, but that would not change the port or the path.
The port is determined when Tomcat starts up and is 8080 by default. The general port for HTTP is 80, but specific permission is required to bind to ports below 1024. On Linux, the authbind package makes this pretty easy; on Windows, the necessary steps will depend on your version and configuration (e.g., if you have a Group Policy).
In Tomcat, Web applications are prefixed with their names in the path; it looks like your (hypothetical?) application is named java-web.war. You can install an application as the "root application", but this requires a little bit more configuration and is generally skipped in development.
All of this can indeed also be done using something like mod_rewrite, but that seems like overkill to have slightly prettier URLs for your dev machine.
If you want your application to respond to the my-local-app.dev, you need to purchase the "my-local-app.dev" domain and get a Java web hotel running on it.
If your web application is named "java-web" and you do not want the URL to reflect that, you need to tell Tomcat that you want your application deployed at the ROOT location where the name of the web application is not present in the URL. This is typically done in the deployment stage but unfortunately there is no standard location to say this for WAR files so this is vendor dependent. For example does Glassfish use an extra XML file in your deployment.
I believe Tomcat supports this for ROOT.war files. If not, you probably needs to set the META-INF/context.xml file. See https://tomcat.apache.org/tomcat-7.0-doc/config/context.html for details on what to put in this file - especially the context path.
How to activate JMX on my JROCKIT JVM for access with jconsole?
(somewhat a follow up question to How to activate JMX on my JVM for access with jconsole?)
The main reason I ask is, because I get strange errors if I try to run jboss (6.0.0.Final) with activated JMX, and jboss doesn't start correctly. So maybe it is a jboss problem.
The easiest way to do this, and at the same time support a variety of potential networking configuration challenges, as well as work with any JVM (most ?) is to install a JMXConnectorServer in the JBoss App Server. Now you're using standard J2SE connectivity.
Older builds of JBoss 6 had this support built in and I'm not sure why jboss removed it but here's how you can recreate it.
Find the jar jboss-as-jbossas-jmx-remoting.jar which has a maven signature of org.jboss.jbossas / jboss-as-jbossas-jmx-remoting. Copy it to the [jboss-home]/server/[your-server]/lib directory.
Create a file like jmx-connector-service.xml as outlined below and drop it into your [jboss-home]/server/[your-server]/deploy directory.
(Sorry, was having trouble formatting XML for stackoverflow).
When the server starts, you will see a log statement like this, pretty early on:
INFO [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://10.213.14.95/jndi/rmi://10.213.14.95:1090/jmxconnector
You can tweak the bindings, the use of a registry, the ports etc, but now you can open JConsole and connect to service:jmx:rmi://10.213.14.95/jndi/rmi://10.213.14.95:1090/jmxconnector.
You can find more information on the service here.
I have a set of EJBs and other Java classes which need to be configured differently based on the system environment in which they are deployed: production, test, or lab. The configuration information includes stuff like URLs and database connection information.
We'd like to deploy the same exact product (EAR file) in each environment, and have the code then figure out where it is and what its configuration should be, without having to reach out to each deployment server in each environment to make changes.
What is the best way to configure all these components in a centralized, reliable, easy-to-maintain fashion?
Thanks for your thoughts.
The best, IMHO, is to use JNDI entries.
You may have to recode some parts of your application in order to use theses entries instead of plain vars, but with this setup:
Configuration is server-independant: each vendor provides its own implementation, but spec is a standard.
In a clustered environment, config can be persisted in a cluster-wide JNDI tree (see JBoss)
Configuration can be changed thru webadmin without restarting server.
How database connection pool information is stored / configured depends on the app server vendor. Put other variable stuff in property files on the classpath.
If you are deploying the exact same EAR to three different instances of a certain container than you will have to edit the deployment settings as there is no way that the deployment process could have any idea about which one of your three versions you would like to use at a particular deployment.
Deployment settings should go into JNDI entries as Piere-Yves said above.
If I were you, I would have my deployment-script (Ant?) properly populate the JNDI entries depending upon which environment you are deploying to.