In JBoss 2.4.3, any threads started by an MBean don't appear to have the classes in the MBean jar available to them. From the MBean, after I've created the thread object, I've tried setting it's classloader equal to the MBean's classloader using setContextClassLoader. The result was the same: classes in the MBean jar are not available to the thread.
Any way to make this work? I don't want to put the classes in the JBoss startup classpath, since they include the home and remote interfaces for an EJB, which would break hot deploy for that EJB. Thanks for any suggestions.
Guy Rouillier wrote:
I figured out a solution, though I still don't understand what is going on. Basically, we have class A in jarA starting up a thread, running class B in jarB. class B is where I'm trying to do the narrow that is failing. What I found was that putting myEJBHome.class into jarA didn't help. Putting it into jarB fixed the problem. As a reminder, jarA contains an MBean. Does this mean that when I start up a secondary thread, the only classes that thread can see are those in its own jar, plus any that we put in the JBoss classpath at startup time? This doesn't make sense to me. If it matters, jarA is added as a ClassPathExtension. What is the difference between a jar added to the startup JBoss classpath and one added as a ClassPathExtension?
Guy Rouillier wrote:
We are still using JBoss 2.4.3 (moving quickly as possible to 3.2.1) on JDK 1.4.2. We have an EJB that invokes an MBean. For the sake of discussion, call the classes myEJB, myEJBHome and myMBean. myEJB does a lookup of myMBean and then invokes a method there. Under some circumstances, myMBean will start up a new thread and on that new thread, do a lookup on myEJB, narrow the reference to myEJBHome, then invoke a method on myEJB.
This all works fine if we put myEJBHome into a jar file that is put in the JBoss classpath at startup time. However, we've switched to not doing that so we have properly packaged EJBs that redeploy properly etc. So now, myEJBHome is only in myEJB.jar, and I've added it to myMBean.jar (and a different client jar that is not part of this discussion.) Now, the second thread appears to get a reference to myEJB, but when it tries to narrow that to myEJBHome, it gets a class not found.
I don't understand how it cannot be finding this class if I've put it into myMBean.jar. I'm sure the answer is in the black hole of classloaders, but unfortunately I haven't mastered that art yet. I did print out System.getProperty("java.class.path") just before the lookup in the 2nd thread, and it has the myMBean.jar file in it. But I guess that thread must not be using the system class path.
Any idea what is going on here? Do I need to explicitly set the classloader for the 2nd thread? The API documentation says that if I don't specify it, I'll get the one used by the creator of the thread. How can I find out what class path the 2nd thread is using? I looked at the ClassLoader class and I don't see any way to get the classpath from it (I suppose since class loaders are not limited to classpaths.) Appreciate any pointers.
-- Guy Rouillier
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
