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. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
