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:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
