Hi, Wow, what a long message ;) I don't have time to reply to everything, but the general answer is: tomcat is a servlet/JSP container at this point. Not a J2EE container. Inter-operating with remote J2EE servers, at least for us, has proven easy. We've never used tomcat 3.x, only 4.x, so I can't comment on version differences.
One more comment is that the weblogic.jar distribution is, IMHO, one of the best examples of how NOT to package things. You simply got lucky that it had javax.xml.transform, along with a ton of other things that don't belong in there. Just look at the weblogic boards and mailing lists to see how many times they've been slammed and requested to split their jar into smaller pieces. For example, some of our apps only need to send JMS messages to a remote weblogic server, so we've had to take out everything non-JMS/JNDI related from the weblogic.jar and repackage it. I'm also curious as to what version of the JDK you are using. >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? No to the first question, yes to the second. It depends by what you mean by J2EE interoperability. Tomcat implements the servlet and JSP specs, which define very specific facilities (ejb resource definition in web.xml, etc.) for interaction with the broader J2EE world. Using tomcat with the J2EE SDK won't give tomcat any magical features. >2. Why is there no javax.xml.transform implementation inside the apache >Tomcat distribution? That's not part of tomcat. It's usually distributed with your parser (e.g. Crimson or Xerces), or more recently with JDK 1.4.x. >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, and they have been for tomcat. >4. How is one supposed to develop a reasonable plan/approach for J2EE >interoperability? Or is interoperability a bad idea? I would say that interoperability is not a bad idea. I think it's a good thing. The first part of developing a reasonable plan / approach would be to understand what your different components, e.g. tomcat if that's what you choose as your "client container", support and don't support. Perhaps you should use JBoss or Weblogic as your "client container" as well? >TOMCAT_HOME/shared/lib. This also provided a usable implementation of >javax.xml.transform. This is one of the main problems. See my comment regarding weblogic.jar above. How do you know what version of javax.xml.transform is inside the weblogic.jar? What if you want to talk to weblogic, but your webapps require a newer javax.xml.transform implementation? >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. I wouldn't rush to conclude this assumption is true. I think it bears more investigating. If both classloader chains are self-consistent, i.e. no conflicting versions of classes in either chain, you should be fine. >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. Why is this "fine"? I think moving weblogic.jar to /WEB-INF/lib is a good step, but weblogic.jar has too much conflicting stuff in it. >else! Fine, we added xalan.jar to TOMCAT_HOME/shared/lib. We then blew up If you add this and don't remove the other javax.xml.transform implementation, i.e. the one in weblogic jar, you can expect a blow-up. >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. See above comments regarding tomcat is not a J2EE server, doesn't claim to be. >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. I agree that this is not a good approach. Keep in mind that for the most part, web applications are supposed to be self-contained. You shouldn't throw anything in the shared libraries unless there's a very good reason for it and no way to package it in the /WEB-INF/lib directory. It all comes down to what you define as "interoperability" ;) Yoav Shapira Millennium ChemInformatics
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
