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... hmmmm 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
