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? xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
