tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <jfarc...@apache.org>
Subject Re: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Date Wed, 09 Oct 2002 20:45:02 GMT


Andrew Gilbert wrote:

>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?
>
Tomcat doesn't have direct relationships with EJB 2.0 specs. If you use 
remote interface, calling them from Tomcat or not doesn't make a difference.

>2. Why is there no javax.xml.transform implementation inside the apache Tomcat distribution?
>
Because those packages comes with the parser (see Xerces/Crimson 
documentation) or are bundled with JDK 1.4.

>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?
>
Yes

>4. How is one supposed to develop a reasonable plan/approach for J2EE interoperability?
Or is interoperability a bad idea?
>
What do you means exactly?

>
>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? 
>
Well, I don't think it's related. This error usually occurs when your 
initial home/remote interface skeleton are in your classpath By initial, 
I mean before deploying your app. You need the home/remote interface 
skeleton that are generated *after* the deployment in your classpath. 
WebLogic probably add some IIOP stuff in your home/remote interface.

>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.
>
Which version of Java are you using?

>
>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? 
>
Its mandatory if you are using a J2EE 1.3 Compatible implementation.

>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?

>
Yes. Tomcat doesn't need to know anything about J2EE API.

>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.
>
Ya...this is certainly not the solution. Have you try deploying your 
stuff with the Sun J2EE's RI 1.3?

-- Jeanfrancois

>
>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>
>
>
>  
>


--
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