tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Gilbert" <and...@soundbite.com>
Subject Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Date Wed, 09 Oct 2002 19:54:25 GMT
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:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message