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