Comments are inline. > Our default optimization of ejb calls through the remote interface > is not working with the servlet 2.3 container class loading model [...] > We can deal with this by either > > 1. ignore the servlet 2.3 class loading model, which is what > Jetty does by default Sounds good, nice and simple and clear. Unfortunately, I believe it is relatively common thing for webapp designers to want to use the 2.3 feature to allow them to, for example, use their favourite xml parser instead of the container provided one.
> 2. transform an ear deployment into a canonical representation where the war > classes are promoted to an ear level class loader We could force the web container to always delegate class loading to the ear class loader, with the provisio that the ear class loader would have to implement 2.3 behaviour (ie allow ear classes to take precedence) to satisfy existing applications requiring 2.3 compliance. > 3. advocate our own packaging model and claim that the vagaries of the > specs allow for this as an aspect of deployment I think this will just muddy the waters even further. > 4. revert back to trying to perform marshalling of incompatible classes at > runtime based on the caller/callee views Sounds a lot more complex than option 2. Jan _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
