Aye up Simon,
You've hit the 2.3 Servlet Classloader
This is a non-delegating classloader. If you put your
classes in WEB-INF, they are loaded from there instead of
where the EJB gets them.
Different classloaders means different classes.
As you hinted, 2.4.4 got around this by marshalling
(serializing) the object between the ejb container and
the web container.
But this is inefficient, 3.0 doesn't do this anymore.
The best thing to do is to remove the classes from
WEB-INF and let Tomcat delegate the classloading to
JBoss. Same classloader means same class and no
Hey, Adrian. I've had some problems with classloading a few weeks ago that got solved only when I added classes to WEB-INF. Maybe you can help me?
My EAR has two modules: an EJB module and a WAR module. The JSP's in the WAR uses classes from the EJB module. However, Jetty complained about not finding these classes while compiling the JSP files. To solve this, I packed theses classes in a separate jar and added it to the WEB-INF/lib dir of the WAR file.
Can I get rid of this extra jar? It would be good if Jetty delegated the classloading to JBoss, who would look in all application modules for the class.
Am I doing something wrong? Do I need to do anything special so Jetty can see the classes in the EJB jar? I can provide full source code/descriptors if needed.
There is a problem with JSP compilation in JBoss 3.0 and
Jetty at the moment. The nightly tests currently fail.
I believe the Jetty people are working on it.
There's been a lot of discussion about who is
responsible for the classloading. :-)
I think Jetty does delegate classloading to JBoss
(it turns off the 2.3 classloading),
but Jasper (the JSP compiler) doesn't have visibility
on the ejb jars for compilation.
If you run JBoss with JBossMX instead of Sun's
jmxri it works, or at least it did when I tested
a couple of weeks ago.
This has something to do with JBossMX
understanding the context classloader.
We've yet to complete the integeration of JBossMX
and JBoss. There are instructions on how to do this
in the manangement forums for the beta.
Thanks Adey, I'll try that out.
Is that Adey Brock? Saw 'warjort' on some commits. If so, good to hear from you, and now I've got even more confidence..
Shame I haven't got time to contribute, I could keep you busy sorting out my rubbish :-)
Mind you, I have got one patch which I really must get round to submitting, which allows JBoss to start up properly on iSeries.
In fact, I think it was in a class you had worked on quite a bit. What's the best way to submit? (OK, I'll read the fine manual in a bit).
Send your patches here.
If it is the problem Martin mentioned, I think it
fixes this bug.
And remember, it's all beer, init?
I was stuck because of the same problem an removing the duplicated
classes from the WEB-INF folder solved it. But if I understand
how this could work with tomcat running as a Jboss service,
I would like to know which solution is used when the servlet
engine and the app server are not running in same box and cant share
their classloader ????
For Tomcat on a different, Tomcat cannot delegate to
JBoss for the classloading. So you will need to include
the classes in your war.
I was having the same ClassCastException problem transitioning to JBoss 3.0 beta, and I understand the class loader problem now, but I think I might need a little more detail as to the solution.
So I need my web container and my EJB container to be loading the same class, right? I understand that I need to remove the offending class from WEB-INF, but how do I tell Tomcat to delegate to the JBoss classloader? In my case, simply removing the class from WEB-INF causes an ObjectMissing error from Tomcat. What specifically do I need to do to have Tomcat locate that class from where my EJB gets them (i.e an EJB jar file)?