If you two are happy - then so am I. If JBoss is responsible for WEB-INF/lib & classes, is Jetty responsible for the classpath that can be set in MANIFEST.MF? Can this override lib & classes or only add to them. Is the top-level of a war also searched for classes? 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... 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 _________________________________________________________ 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
