I'm running the JBoss2.4.4_Tomcat4.0.1 bundle on Solaris 8. My problem is that JBoss doesn't seem to want to recognize the fact that the jboss-j2ee.jar is in the classpath even though from the print out, I can see that it is loaded from lib/ext:
[18:21:24,958,ClassPathExtension] Added library:file:/export/home/openspace/work/development/OpenSpace/Dep
[18:21:24,959,ClassPathExtension] Added library:file:/export/home/openspace/work/development/OpenSpace/Dep
[18:21:24,960,ClassPathExtension] Added library:file:/export/home/openspace/work/development/OpenSpace/Dep
I also looked in the JBoss's server.log and the jar file is in java.class.path too. It deploys the tomcat-test.ear fine so I thought it was my code, but when I explicitly add jboss-j2ee.jar to JBOSS_CLASSPATH in run.sh, it works ( actually, it then complains that it can't find log4j, which has also been loaded from lib/ext, but at least it finds jboss-j2ee.jar). I found another post with the same problem, but no reply:
My output is below. Does anyone have an idea of what's going on? Thanks very much in advance and for this forum.
[18:21:47,824,J2eeDeployer] Create application smi-adm-ejb.jar
[18:21:47,825,J2eeDeployer] install EJB module smi-adm-ejb.jar
[18:21:48,180,ContainerFactory] Verifying file:/export/home/openspace/work/development/OpenSpace/Deploy/Ap
[18:21:48,349,ContainerFactory] Verify failure
at java.lang.ClassLoader.defineClass0(Native Method)
at java.security.AccessController.doPrivileged(Native Method)
...and so on
Can you give some details about how you have packaged
You shouldn't have to add anything to your classpath.
There is a service at the top of jboss.jcml that adds
everyting in lib/ext to it. This is obviously running
because that is the first part of your post.
There are lots of problems posted about classpaths
that involve confusion between Sun's j2ee.jar and jboss-j2ee.jar.
Make sure you don't have Sun's version in
your classpath or lib/ext of JAVA_HOME/jre/lib/ext
or anywhere else this might cause confusion.
> Can you give some details about how you have
> this jar.
That's right, I did forget to mention that I separated out the EJB code and the business logic using inheritance so that the EJB Remote interface, Home interface, and Bean class do not actually contain any functionality. Ie, the Bean class only has ejbCreate, ejbRemove, ejbActivate, ejbPassivate, and setSessionContext; it inherits all of the business logic from another class packaged in a jar file in the client dir (same goes for the Remote interface: it inherits all the business logic by extending another interface). I explicitly include this client jar file in the JBOSS_CLASSPATH in startup.sh.
I don't think it's the inheritance that's causing this though cause I tried reorganizing so that all the functionality is in EJB and it still gave me the same error.
Besides the Home, Remote, and Bean classes i just have my META-INF/jboss.xml and META-INF/ejb-jar.xml in the jar file.
> Make sure you don't have Sun's version in
> your classpath or lib/ext of JAVA_HOME/jre/lib/ext
> or anywhere else this might cause confusion.
Nope, I just the jboss-j2ee.jar
Have you tried putting client.jar
another alternative is to create a .ear
Don't use JBOSS_CLASSPATH.
I saw a post some time ago that said it was called
this to show JBoss didn't use the CLASSPATH
environment variable, although I've also seen posts
where people say dump whatever you like in there :-)
Everyting in lib/ext is easy and doesn't require
any editing of scripts.
It also stops confusion between the class loaders
like your log4j problem.
> Have you tried putting client.jar
> in lib/ext
> another alternative is to create a .ear
> Don't use JBOSS_CLASSPATH.
Yep...it looks like JBOSS_CLASSPATH is pretty sensitive to changes I've made and that's confusing the class loaders. I put the jar files in lib/ext, used the original JBOSS_CLASSPATH and it deployed fine. I was hoping to put folders in lib/ext though but that could be getting nitpicky :)
Thanks for the help.
> Everyting in lib/ext is easy and doesn't require
> any editing of scripts.
> It also stops confusion between the class loaders
> like your log4j problem.
You can have directories.
Have a look in conf/????/jboss.conf at classPathExtension.
NOTE: Everything is relative to the location of jboss.conf.
If you add
Providing you don't put a .jar or .zip in there
it will add the lib/ext/mydirectory to the classpath.
Putting a .jar or .zip in there, will only add the .jar
or .zip to the classpath.
Make a sentence out of the following words.
it eat and cake your have :-)
Sweet! Thanks much Adrian...
> You can have directories.
> Have a look in conf/????/jboss.conf at
> NOTE: Everything is relative to the location of
> If you add
> ARCHIVE="jboss.jar" CODEBASE="../../lib/ext">
> Providing you don't put a .jar or .zip in there
> it will add the lib/ext/mydirectory to the
> Putting a .jar or .zip in there, will only add the
> or .zip to the classpath.
> Make a sentence out of the following words.
> it eat and cake your have :-)