Re: [JBoss-dev] Optimizations, packaging and the servlet 2.3 class loading model
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
[JBoss-dev] Optimizations, packaging and the servlet 2.3 class loading model
Our default optimization of ejb calls through the remote interface is not working with the servlet 2.3 container class loading model that advocates: servlet-2.3-spec SRV.9.7.2 Web Application Classloader The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. It must not allow theWAR to override J2SE or Java servlet API classes. It is further recommended that the loader not allow servlets in theWAR access to the web container's implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. /servlet-2.3-spec When combined with this example ear structure given in the j2ee 1.3 spec: app3.ear: META-INF/application.xml ejb1_client.jar ejb3.jar Class-Path: ejb1_client.jar webapp.war webapp.war: WEB-INF/web.xml WEB-INF/servlets/servlet1.jar Class-Path: ../client_views/ejb1_client.jar WEB-INF/client_views/ejb1_client.jar Calls from a servlet to an ejb through the remote interface fail due to two class loaders having loaded the ejb remote interface class. The recent change to not serialize objects bound into JNDI inside of the server also shows the same problem as the class loader in effect when the homes are bound does not match the class loader of the servlet. We can deal with this by either 1. ignore the servlet 2.3 class loading model, which is what Jetty does by default 2. transform an ear deployment into a canonical representation where the war classes are promoted to an ear level class loader 3. advocate our own packaging model and claim that the vagaries of the specs allow for this as an aspect of deployment 4. revert back to trying to perform marshalling of incompatible classes at runtime based on the caller/callee views What do we want to do? Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
