|We (Jetty) need to understand exactly how the new classloader strategy is |expected to work and what the contract between JBoss and Jetty has |now become, |with respect to this new behaviour, because we need to come up |with a solution |that will work for JBoss/Jetty and standalone Jetty.
|> |I am using the current tip (9 am this morning). This ear deployed and |> |worked before (the marc unified class loading) and now I am getting a |> |class not found exception. Inside the war is |> | |> |WEB-INF/classes/tests/cadex/TestCompanyInfoBean.class |> | |> |Error finding class [tests.cadex.TestCom |> |panyInfoBean] in classpath |> |java.lang.ClassNotFoundException: tests.cadex.TestCompanyInfoBean |> | at |> |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:405 |> |) |> | at |> |org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoader.java |> |:101) |> | at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |> | at |java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |> | at java.lang.Class.forName0(Native Method) |> | at java.lang.Class.forName(Class.java:120) |> | at |> |org.apache.cactus.server.AbstractTestCaller.getTestClassClass(Abstrac Ok this is the way I read this. Dave, AbstractTestCaller is your servlet class, how is this one deployed? an ear? a war? a jar? what are those apache jars? It appears that it is loaded by a JBoss UCL, that JBoss UCL is the parent of the Jetty CLs so when that class is created the class that returns is from JBoss UCL. Then the code has a thread going to the jetty stack and the jetty stack delegates to this object and this object does a class.forName() (!!!! fuck when will the newbies learn!!!)instead of a Thread.currentThread().getContextClassLoader() that would return the Jetty CLs and then the path would be Class->JettyCl->JBoss UCL says no->Jetty CL says yes everything OK. But since they didn't use the context classloader we are stuck with the CL for the class which is JBoss' UCL. Solutions: 1- Jetty uses JBoss' UCL in our integration. Problem is gone, that is why we develop the UCLs today. 2- Jetty CLs bypass the JDK parent delegation model and do explicit creation of classes from their classloaders. So any new class seen by Jetty is loaded by Jetty CL, delegated to JBoss CL if not found. THIS IS SPEC COMPLIANT. THIS COMPLETELY BREAKS THE INTEGRATION as the Jetty Classes would not be seen as loaded by the same classloaders as the JBoss classes. You want to share classes? tough it out. 3- I code WARDeployer parsing of the webinf/classes (simple), we can code a fancy "granularity" if need be (scott's point) but priority is to integration and ease of use. Never breaks, can be made spec compliant. This is transparent to Jetty (bypasses its management of web-inf/classes) 4- The user stop bothering us with more packaging non-sense from SUN, puts all his support classes in a jar in the next 30 seconds, drops that jar either separate either AT ANY LEVEL of the ear (top, or under WEB-INF/Classes/myClasses.jar) or whatever and that will be deployed properly AS IS by JBoss without further ado and will work transparently on Jetty. 5- Apache developers get their shit together and STOP doing class.forName(). My order of preference is 5/ 4/ (make use of the new deployer and stop bothering us :) 3/ easy spec compliance 2/ and then 1/ Looking at it I can get 3 out the door in 40 minutes flat without dealing with the bureaucracy at Apache and such. jules, gregw, let me know... marcf PS: Was this really working before? if so it means we were parsing the WEB-INF/classes ourselves??? strange... I don't remember that. Besides the point. |> |tTestCaller.java:331) |> | at |> |org.apache.cactus.server.AbstractTestCaller.getTestClassInstance(Abst |> |ractTestCaller.java:302) |> | at |> |org.apache.cactus.server.AbstractTestCaller.doTest(AbstractTestCaller |> |.java:130) |> | at |> |org.apache.cactus.server.AbstractTestController.handleRequest(Abstrac |> |tTestController.java:122) |> | at |> |org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedi |> |rector.java:134) |> | at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) |> | at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) |> | at |> |org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:327 |> |) |> | at |> |org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 |> |46) |> | at org.mortbay.http.HttpContext.handle(HttpContext.java:1269) |> | at org.mortbay.http.HttpContext.handle(HttpContext.java:1223) |> | at org.mortbay.http.HttpServer.service(HttpServer.java:725) |> | at |> |org.mortbay.http.HttpConnection.service(HttpConnection.java:748) |> | at |> |org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:921) |> | at |org.mortbay.http.HttpConnection.handle(HttpConnection.java:763) |> | at |> |org.mortbay.http.SocketListener.handleConnection(SocketListener.java: |> |138) |> | at |org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) |> | at |org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) |> | at java.lang.Thread.run(Thread.java:484) |> | |> | |> | |> |_______________________________________________ |> |Jboss-development mailing list |> |[EMAIL PROTECTED] |> |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |_________________________________________________________ |Do You Yahoo!? |Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
