I have a weird problem with an application client that I want to put in a self-contained JAR file, so it can be executed on any machine without having to install additional software or libraries.
The application client works well if I call the main class directly, with the four required JBoss client classes in the class path.
But if I try it from the JAR, what I get is this:
java.lang.Exception: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
Caused by: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
... 1 more
This is the jndi.properties file, which I included in the 'Class-Path' field of the MANIFEST.MF file:
These are the JBoss JAR files that I included in the application client's JAR file, and which are also included in the 'Class-Path' fields of the manifest, as mentioned above:
(I put the five files - the jndi.properties and the four client JARs - each in their own 'Class-Path' field, after I discovered that Ant wrapped the line, but it didn't make a difference.)
I've written a small test application that instantiates a NamingContextFactory object, and put it in a JAR file, with the manifest file and the four client JARs. It works fine.
It seems to me that I have everything covered, yet it complains that it can't locate the NamingContextFactory class. Is it something obvious that I'm overlooking?
You would have to check this one with Sun.
You did say it works when you instantiate the class
Probably some weird classloading behaviour in
the javax.naming classes?
You haven't got to any jboss code yet.
Let me answer my own question for the benifit of others, who may want to do the same thing.
If you provide the 'Class-Path' entry/entries in the manifest file, the application expects those jar files to be in the same directory - not in the application's jar file itself, like I thought it would.
So I would have to manually load the jars from the encapsulating jar. This sounds like more work than I want to put into it, especially since I had already been planning to use Java WebStart.
Obviously, JWS is giving me other problems. :) But at least now, I can put the JBoss client jars in a war, deploy the war and use the JnlpDownloadServlet. All jars are signed, they download well, but I get a security exception that I have to figure out. That will probably be another question on this forum...
Unfortunately, the JBoss administration and development documentation is rather scant on the subject of application clients.
I'm curious now, whats the security exception?
The client security interceptor tries to
access the principal.
You have to give jbosssx-client.jar the rights to do
So where can I find the information about what client jars to include in the package? So far, with trial-and-error I've found jbossall-client.jar, jbossjmx-ant.jar, jnp-client.jar and log4j.jar to work. But it's not anywhere in the JBoss book.
I'll see what happens when I change the <j2ee-application-client-permissions/> tag to <all-permissions/>.
OK, I got everything working now. I think the best way to distribute an application client is Java WebStart, since it takes care of loading the various JAR files and putting them in the classpath.
I used these client JARs:
The properties, which would normally go into the jndi.properties files, I set in the JNLP file. I selected <all-permissions/> rather than <j2ee-application-client-permissions/> to avoid any security exceptions. And then it worked.
I would like to suggest that the JBoss book spends a lot more attention on how to build a client.
Please post the properties section of the jnlp descriptor that you used to set up the JNDI properties. I'm having problems with this.