> Hi all,
> If anyone else out there is playing with JBoss 3.0, I
> have a solution to a problem that might be causing
> some people headaches right now. Before 3.0, you
> could add external classes to JBoss by dropping them
> in the lib\ext directory. However in 3.0, if you want
> to add a Jar/Zip file that contains classes used by
> your beans you need to add an entry to the
> conf\default\jboss-service.xml file. In that file,
> look for the element, and add your
> Jar/Zip file to the comma seperated list in the
> archives attribute.
> I hope that this info helps!
It does but really that behavior was a mistake introduced by one of the developers. Explicitely listing all the jars is really unnecessary from a administration standpoint. I am about done with a new deployer that brings back the simple behavior of "add lib/ext and go" while keeping the hot deploy nature of 3.0 microkernel.
Thats good to hear!
While on the topic of the deployers, I'm investigating a possible problem with 3.0 where it seems as if the current mechanism with loading external classes is not able to find .properties files. Would this be something that is likely to be fixed by your new stuff or is should I keep digging around the code thats in there right now?
Marc, it looks to me as if there is already way to get all of lib/ext into the classpath with the current code: include
in the main jboss-service.xml. This is essentially the same as what was in your original checkin (archives have changed from "" to "*"). It's kind of silly to have to include the codebase, but this was in your original code also. Changing it to accept
is pretty trivial.
I don't see how anything has been removed or broken.
I think all this confusion started when you originally listed all the jars to demonstrate web deployment. The code to load everything has been there all along. I assumed since you didn't use it you didn't think using it was appropriate (personally, I still don't, for the same reasons we don't encourage import packagename.*).
Alan Lewis, where are your .properties files and how are you trying to access them?
David - My bean needs to access a .properties file that needs to be on the JBoss classpath. It is a license file that the bean needs in order to run (it is a third-party bean). When I simply stick the .properties file in lib\ext, the bean does not find it, even after I add the codebase attribute to the classpath element as demonstrated in your previous post. However, I just tried packaging the .properties file in a jar file and adding it to the archives attribute, and that seems to work ok, although I get still get weird error messages like this:
[12:48:33,117,Default] Did not find the UCL resource org/apache/xerces/utils/reg
[12:48:33,227,Default] Did not find the UCL resource org/apache/xerces/utils/reg
[12:48:33,547,Default] Did not find the UCL resource org/apache/xerces/msg/XMLMe
[12:48:33,658,Default] Did not find the UCL resource org/apache/xerces/msg/XMLMe
that seem to indicate that when I added xerces.jar to the classpath I did not configure it correctly...
So although I have a workaround for the .properties file problem, another one has come up: the bean that I use also needs OROMatcher on the classpath. OROMatcher comes packaged as a zip file, and I assumed that by putting it in the archives list in the jboss-service.xml file that it would be included. Is there another attribute that you use to include Zip files?
I have rewritten the deployer and I am about to commit it, simpler more straightforward,
I am using Jboss3.0.0beta and my beans are not able to locate a props file. I followed alan's method and put the props file in a jar file and placed the jar file in lib/ext. But the bean still complains of not being able to find the properties file. Any ideas on how I can solve this ??