We are finding this a particularly frustrating experience, and it seems to be a "weak" point either/or both in specification and implementation (or a fatal flaw in our basic approach - but would add we are consistent at least with the "intent" of the EJB specs). Would appreciate input and enlightenment.
Questions: 1. Should one assume use of the J2EE SDK distribution of Tomcat is required for J2EE interoperability, per 2.0 spec? More directly, is it reasonable to try to get J2EE interopability with the apache distribution of Tomcat? 2. Why is there no javax.xml.transform implementation inside the apache Tomcat distribution? 3. For a J2EE container to be "interoperable" per the spec, would it be reasonable to assume this means class loading issues inside the "client" container have been tested/addressed? 4. How is one supposed to develop a reasonable plan/approach for J2EE interoperability? Or is interoperability a bad idea? Summary: In our case we are trying to upgrade to Tomcat 4.1.12 under Win2K to interoperate with WL 7.01. We have two web applications deployed under Tomcat, referencing EJB's and DataSources running inside WL. The web applications also require an implementation of javax.xml.transform. We are currently successfully deployed using Tomcat 3.3 and WL 5.1 (using T3). In our first attempted new configuration, we opted to use WL T3 (ie weblogic.jar) to communicate from Tomcat to WL. Placed this in TOMCAT_HOME/shared/lib. This also provided a usable implementation of javax.xml.transform. Our application jars are all placed in WEB-INF/lib. Problem occurred when referencing an EJBHome first from one web app, then subsequently from another. Led to class cast exceptions when doing the narrow on PortableRemoteObject. Assumption is because a given home is now loaded in two separate class loaders, this is causing problems? Don't know exactly. The home remote stub gets loaded by a WL classloader whose parent is the WebppClassLoader, whose parent is the StandardClassLoader for "shared". The home interface is loaded by the WebappClassLoader, whose parent is the StandardClassLoader for "shared". Interception. In a second attempted configuration, tried to move weblogic.jar down from TOMCAT_HOME/shared/lib to WEB-INF/lib. This has side affect of warning messages about not loading javax.servlet per 2.3 spec section 9.7.2. Fine. It also appeared to result in loss of the javax.xml.transform implementation in weblogic.jar. Looks like something to do with not messing with JAXP from WEB-INF, only the classes in question don't exist anywhere else! Fine, we added xalan.jar to TOMCAT_HOME/shared/lib. We then blew up on first attempt to use a WL hosted DataSource, with class not found issues. This looks like issues with javax.sql classes that have been loaded higher up the loader hierarchy not being able to find stuff down inside WEB-INF/lib. Punt. In considering a third configuration, we began investigating using RMI-IIOP to communicate with WL. In theory this should be possible per EJB spec 2.0 section 19? First immediate problem seemed to be that Tomcat has no javax.ejb classes available. Would seem these classes are only available when running Tomcat under the J2EE SDK distribution? In general uncertainty about this, and whether it will even address class loading issues, has caused us to wait before proceeding. Fumble. Finally, a fourth configuration was tried which seemed to have some promise, with a serious drawback. Would appear that things basically work if we put everything, weblogic.jar, jdbc drivers, application jars, testing jars, etc into TOMCAT_HOME/shared. Unfortunately, this pretty much eliminates/defeats any hope of deploying applications without tearding down the container and also complicates the build/deployment process as we can no longer just throw a new .war file over the wall at operations. Penalty. Any feedback is appreciated. Andrew -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
