RE: [JBoss-dev] Status of ear deployment
|If JBoss is responsible for WEB-INF/lib classes, is Jetty what is in web-inf/lib just straight jars/wars/? If so that is taken care of already. classes is the flat stuff right? classes in a flat directory. |responsible for the |classpath that can be set in MANIFEST.MF? Can this override lib I take care of ALL manifest craziness and most of it doesn't need to be set intra war. |classes or only |add to them. Is the top-level of a war also searched for classes? a war is added as a class source/page source. So yes it is added, not searched just plain added. marcf |I have seen this |used, but never checked to see if it was explicit or implicit behaviour. | |Jules | | | |Greg Wilkins wrote: | | Sorry, but I've been away from my computer, so I have not been |able to contribute | to this discussion | | But looking over what has been said - my quick response is | | If WARDeployer is handling the WEB-INF/lib jars *and* the WEB-INF/classes | directory, then I think the simplest thing to do is to switch the | Jetty CL into J2 compliant mode (ie always delegates). | | This means that whatever policy is selected (Servlet compliant |or J2 compliant) | will be implemented in a single place within JBoss. Jetty's |own interpretation | of the servlet spec and changes to it's definition of System |class will not | effect the running of JBoss. | | Actually, I'll look at changing Jetty so that it can use JBoss's |classloader | directly and then we don't need to bother with any delegation. | | But as I said, this is my quick response as I once again rush |out the door... | I'll read everything again late tonight and send a more |considered response. | | cheers | | marc fleury wrote: | Sorry thinking some more and answering some | | |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. | | Well come to think of it it only breaks integration if we are *sharing* | classes. Duplicate classes in /webinf/classes and some other |package (EJB or | another servlet) would not be seen. | | The proper way to do integration (classes seen by this ear/war |and other | classes) is to move the classes out of there. So in fact having Jetty | implement the spec and look for classes locally and then |delegate to JBoss | would only break integration in case the user duplicates |classes in their | packages and is looking for sharing. This looks OK. | | |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) | | This is really my favorite now. I am working on the |assumption that dave is | not full of shit and that this package was indeed working |before, this means | that we were parsing the webinf/classes in OUR deployer already, unless | jetty was implementing a 2/ solution before which it wasn't. | | Greg, note that if I implement 3 right now and you implement 2 |your 2 will | override 3 (you will find the class in the 2 step and not go |with the UCL | from 3/ therefore have exactly the same effect). In other |words you are | free to implement your spec compliance and do away with parent |delegation as | requested by the spec (which is dumb imsho) with the knowledge and | understanding that | 1- this is irrelevant to the case standalone or not it only |comes into play | if you have a CL to delegate to (JBoss parent in this case). | 2- it will only break integration of shared classes. But that |is the spec | for you. | | I think I have reached a conclusion on my part. | a/ I will go ahead with 3/ | b/ you can override by implementing your JettyCL that do servlet spec | compliance on ordering but if you don't and just delegate as |is, we have | integration. | | And thus speed. | | Anything for speed. | | | |4- The user stop bothering us with more packaging non-sense |from SUN, puts | | this is un-realistic :) | | |5- Apache developers get their shit together | | and so is this. | | marcf | | WAIT WAIT WAIT | | PS: 1/ (UCL in Jetty) would give us spec compliance AND |integration, but I | would rather do the work myself... although that would be one |place where | having the JBoss/Jetty codebase becomes interesting... h |maybe this is | simpler even though it is really a fork from the jetty base. | | | | -- | Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 | Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
[JBoss-dev] Status of ear deployment
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 and when I try to access it via a servlet I get (see below) known problem? bug ? Dumb user? 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 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
Re: [JBoss-dev] Status of ear deployment
WEB-INF/classes should not be handled by the unified class loader as web containers typically allow classes under this directory to be dynamically updated. - Original Message - From: marc fleury [EMAIL PROTECTED] To: Dave Smith [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Julian Gosnell [EMAIL PROTECTED] Sent: Tuesday, February 05, 2002 5:03 PM Subject: RE: [JBoss-dev] Status of ear deployment Jules, the unified deployer on WAR just delegates to you. I ignore the WEB-INF/classes although it would be quite trivial to deploy it at the UCL level. Should this be done internally to your deployer in which case you want to use a UCL to point to wherever to unpack the WEB-INF/classes (under Jetty control) and you feed it to the UCL, which will then find these. Or I do it, in the WAR deployer, you tell me no biggy. Dave, the simplest to get this working right now is to include a jar with your classes inside the ear at any level (top is good) that will deploy your classes right now. Jules let me know if you want to take care of that, or I can do it. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dave |Smith |Sent: Tuesday, February 05, 2002 1:10 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Status of ear deployment | | |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 | |and when I try to access it via a servlet I get (see below) |known problem? bug ? Dumb user? | | |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 |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Status of ear deployment
Either : This is a new bug in Jetty - unlikely Or: It is a misunderstanding about ClassLoading between JBoss Jetty - very likely since this has all reecently changed in JBoss. - much more likely. 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. This is really Greg's area, so I invite him to join the fracas. You there, Greg ? :-) Jules (sidestepping and ducking) marc fleury wrote: Jules, the unified deployer on WAR just delegates to you. I ignore the WEB-INF/classes although it would be quite trivial to deploy it at the UCL level. Should this be done internally to your deployer in which case you want to use a UCL to point to wherever to unpack the WEB-INF/classes (under Jetty control) and you feed it to the UCL, which will then find these. Or I do it, in the WAR deployer, you tell me no biggy. Dave, the simplest to get this working right now is to include a jar with your classes inside the ear at any level (top is good) that will deploy your classes right now. Jules let me know if you want to take care of that, or I can do it. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dave |Smith |Sent: Tuesday, February 05, 2002 1:10 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Status of ear deployment | | |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 | |and when I try to access it via a servlet I get (see below) |known problem? bug ? Dumb user? | | |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 |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
RE: [JBoss-dev] Status of ear deployment
|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) | |
RE: [JBoss-dev] Status of ear deployment
Sorry thinking some more and answering some |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. Well come to think of it it only breaks integration if we are *sharing* classes. Duplicate classes in /webinf/classes and some other package (EJB or another servlet) would not be seen. The proper way to do integration (classes seen by this ear/war and other classes) is to move the classes out of there. So in fact having Jetty implement the spec and look for classes locally and then delegate to JBoss would only break integration in case the user duplicates classes in their packages and is looking for sharing. This looks OK. |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) This is really my favorite now. I am working on the assumption that dave is not full of shit and that this package was indeed working before, this means that we were parsing the webinf/classes in OUR deployer already, unless jetty was implementing a 2/ solution before which it wasn't. Greg, note that if I implement 3 right now and you implement 2 your 2 will override 3 (you will find the class in the 2 step and not go with the UCL from 3/ therefore have exactly the same effect). In other words you are free to implement your spec compliance and do away with parent delegation as requested by the spec (which is dumb imsho) with the knowledge and understanding that 1- this is irrelevant to the case standalone or not it only comes into play if you have a CL to delegate to (JBoss parent in this case). 2- it will only break integration of shared classes. But that is the spec for you. I think I have reached a conclusion on my part. a/ I will go ahead with 3/ b/ you can override by implementing your JettyCL that do servlet spec compliance on ordering but if you don't and just delegate as is, we have integration. And thus speed. Anything for speed. |4- The user stop bothering us with more packaging non-sense from SUN, puts this is un-realistic :) |5- Apache developers get their shit together and so is this. marcf WAIT WAIT WAIT PS: 1/ (UCL in Jetty) would give us spec compliance AND integration, but I would rather do the work myself... although that would be one place where having the JBoss/Jetty codebase becomes interesting... h maybe this is simpler even though it is really a fork from the jetty base. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Status of ear deployment
Thanks, Marc, for taking the time to spell this out Hopefully Greg will come on line soon. I'm sure he'll have some comments. I'll get back to you all when I have had chance to think about this, probably tomorrow night. My gut feeling is that: 1. If a quick fix is available, perhaps we should take it for 3.0 2. The quick fix is probably exactly that, and will probably need revisiting soon, but at least it might buy us the time to sort out a long-term solution. Speak to you then, Jules marc fleury wrote: Sorry thinking some more and answering some |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. Well come to think of it it only breaks integration if we are *sharing* classes. Duplicate classes in /webinf/classes and some other package (EJB or another servlet) would not be seen. The proper way to do integration (classes seen by this ear/war and other classes) is to move the classes out of there. So in fact having Jetty implement the spec and look for classes locally and then delegate to JBoss would only break integration in case the user duplicates classes in their packages and is looking for sharing. This looks OK. |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) This is really my favorite now. I am working on the assumption that dave is not full of shit and that this package was indeed working before, this means that we were parsing the webinf/classes in OUR deployer already, unless jetty was implementing a 2/ solution before which it wasn't. Greg, note that if I implement 3 right now and you implement 2 your 2 will override 3 (you will find the class in the 2 step and not go with the UCL from 3/ therefore have exactly the same effect). In other words you are free to implement your spec compliance and do away with parent delegation as requested by the spec (which is dumb imsho) with the knowledge and understanding that 1- this is irrelevant to the case standalone or not it only comes into play if you have a CL to delegate to (JBoss parent in this case). 2- it will only break integration of shared classes. But that is the spec for you. I think I have reached a conclusion on my part. a/ I will go ahead with 3/ b/ you can override by implementing your JettyCL that do servlet spec compliance on ordering but if you don't and just delegate as is, we have integration. And thus speed. Anything for speed. |4- The user stop bothering us with more packaging non-sense from SUN, puts this is un-realistic :) |5- Apache developers get their shit together and so is this. marcf WAIT WAIT WAIT PS: 1/ (UCL in Jetty) would give us spec compliance AND integration, but I would rather do the work myself... although that would be one place where having the JBoss/Jetty codebase becomes interesting... h maybe this is simpler even though it is really a fork from the jetty base. ___ 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
Re: [JBoss-dev] Status of ear deployment
Sorry, but I've been away from my computer, so I have not been able to contribute to this discussion But looking over what has been said - my quick response is If WARDeployer is handling the WEB-INF/lib jars *and* the WEB-INF/classes directory, then I think the simplest thing to do is to switch the Jetty CL into J2 compliant mode (ie always delegates). This means that whatever policy is selected (Servlet compliant or J2 compliant) will be implemented in a single place within JBoss. Jetty's own interpretation of the servlet spec and changes to it's definition of System class will not effect the running of JBoss. Actually, I'll look at changing Jetty so that it can use JBoss's classloader directly and then we don't need to bother with any delegation. But as I said, this is my quick response as I once again rush out the door... I'll read everything again late tonight and send a more considered response. cheers marc fleury wrote: Sorry thinking some more and answering some |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. Well come to think of it it only breaks integration if we are *sharing* classes. Duplicate classes in /webinf/classes and some other package (EJB or another servlet) would not be seen. The proper way to do integration (classes seen by this ear/war and other classes) is to move the classes out of there. So in fact having Jetty implement the spec and look for classes locally and then delegate to JBoss would only break integration in case the user duplicates classes in their packages and is looking for sharing. This looks OK. |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) This is really my favorite now. I am working on the assumption that dave is not full of shit and that this package was indeed working before, this means that we were parsing the webinf/classes in OUR deployer already, unless jetty was implementing a 2/ solution before which it wasn't. Greg, note that if I implement 3 right now and you implement 2 your 2 will override 3 (you will find the class in the 2 step and not go with the UCL from 3/ therefore have exactly the same effect). In other words you are free to implement your spec compliance and do away with parent delegation as requested by the spec (which is dumb imsho) with the knowledge and understanding that 1- this is irrelevant to the case standalone or not it only comes into play if you have a CL to delegate to (JBoss parent in this case). 2- it will only break integration of shared classes. But that is the spec for you. I think I have reached a conclusion on my part. a/ I will go ahead with 3/ b/ you can override by implementing your JettyCL that do servlet spec compliance on ordering but if you don't and just delegate as is, we have integration. And thus speed. Anything for speed. |4- The user stop bothering us with more packaging non-sense from SUN, puts this is un-realistic :) |5- Apache developers get their shit together and so is this. marcf WAIT WAIT WAIT PS: 1/ (UCL in Jetty) would give us spec compliance AND integration, but I would rather do the work myself... although that would be one place where having the JBoss/Jetty codebase becomes interesting... h maybe this is simpler even though it is really a fork from the jetty base. -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
