RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Yoav and JeanFrancios, Thank you both for your replies. They were helpful and somewhat reassuring. At the general level: We are aware that Tomcat is not a full J2EE container. But servlets calling EJB's is bread and butter stuff. We have been successfully using Tomcat to talk to WebLogic for 2 years, so know it can work. But each time we go through an upgrade, of either component, we repeat the same voodoo process of jar, jar, where to put the jar. This jar jungle is a nightmarish flashback to dll hell from C++/Windows days. What we are looking for is two things. One, some reassurance we aren't in the wilderness using Tomcat to talk to WebLogic. Two, a better foundation for developing strategies for handling jar packaging and classloading issues. I think I got a little of both from your replies. At the specifics: We are currently using JDK 1.3.1. Considered the need to break out weblogic.jar, just hoping to avoid it. Will put specific re-packaging of required javax.* classes back back on the list. Cleaning up issues with conflicts, overlaps and gaps in javax.xml.* implementations is one of our motivators to upgrade, so we can also get to JDK 1.4 and get out of the mess. Unfortunately this is a painful catch 22. Have considered using JBoss or WebLogic for our servlet container. This option is still on the table. It has drawbacks, but puts everything inside the same dotted box and thus eliminates some interop baggage. Have also considered using J2EE 1.3 as a container for running Tomcat, thus providing more full J2EE support. Also still on the table. Still not at the root of the class cast exception when running our first choice config. The classloader chains did look consistent and clean. Jean-Francios mentioned something about when the home/remote skeletons get loaded (did you mean stubs?). Will look at this, as it is also consistent with other ideas about how to use RMI-IIOP and the use of the client jar generated from ejbc on the tomcat side. Thanks again. Helpful. But still, feel like we could write a paper on the dark side of J2EE ownership and maintenance. Hopefully someone at Sun is listening... -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 9:28 AM To: Tomcat Users List Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... 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
RE: Connecting from Tomcat box to JBoss box?
Edmund,
See Craig's response to my thread RE: Classpath Issues, Tomcat 4.X and J2EE
Interoperability frustrations...
You might want to go the JBoss to JBoss route. In fact I would strongly recommend it.
Andy
-Original Message-
From: Mitchell, Edmund [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 10, 2002 9:11 AM
To: 'Tomcat Users List'
Subject: Connecting from Tomcat box to JBoss box?
Hello all,
I've got my Apache box talking happily to my Tomcat box,
thanks to John
Turner and Pascal Forget's great webpages, but I can't seem to get the
Tomcat box to talk to the JBoss box.
Does anyone have any how-to type info on how to get this
connection to
happen? I've tried everything in both the JBoss and ejb docs
I've read, to
no avail.
In the post below, Anthony Geoghegan suggests that turning
off the Tomcat
JNDI server will work, but I've been up and down the Tomcat
JNDI docs, and
seen nothing that looks like an off switch. Can anyone shed
some light on
that?
Thanks for any help
Edmund
.
-Original Message-
From: Anthony Geoghegan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 1:20 PM
To: Tomcat Users List; [EMAIL PROTECTED]
Subject: Re: Apache 2, Tomcat, JBoss configuration
You have to use remote interfaces and turn off the TOMCAT
JNDI server to use
the JBOSS JNDI server, otherwise it's fine.
- Original Message -
From: Jim Haggerty [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, October 08, 2002 5:31 PM
Subject: Apache 2, Tomcat, JBoss configuration
Current versions:
FreeBSD 4.6.2-RELEASE
Apache 2.0.42 (although FreeBSD port now has 2.0.43)
Tomcat 4.0.5
JBoss 3.0.0 (NB: This installation is the package WITHOUT Tomcat)
Apache and Tomcat are getting along fine and I can access
deployed webapps
through the warp connection (Is JK2 preferred over warp?)
on both port 80
and 8080.
JBoss is alive and well on port 8082.
However, virtually ALL the documentation I have found
regarding connecting
the three refers to the JBoss+Tomcat package (modify the
server.xml in
${JBOSS_HOME}/catalina). Does anyone have an example of
connecting
Apache -
Tomcat - JBoss WITHOUT JBoss+Tomcat?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Craig, I was slowly coming to the conclusion that approaches 2 and 3 are superior. Having said that, I am still somewhat bothered. It is easy to (naively?) adopt approach 1. The two prior responses seemed to indicate this approach was okay. Yoav is using it. And there is currently another active thread on this list about using Tomcat to talk with JBoss. There is certainly strong natural motivation to want to deploy servlet container(s) toward the edge talking to app server(s) at the core. Seems odd to assert I should only talk to my distributed remote object server by first putting myself inside another distributed remote object server. Anyway, I appreciate your response. Thanks. Andy -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 12:56 PM To: Tomcat Users List Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... On Thu, 10 Oct 2002, Andrew Gilbert wrote: Date: Thu, 10 Oct 2002 11:42:05 -0400 From: Andrew Gilbert [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... Yoav and JeanFrancios, Thank you both for your replies. They were helpful and somewhat reassuring. At the general level: We are aware that Tomcat is not a full J2EE container. But servlets calling EJB's is bread and butter stuff. Only for an EJB server :-). Tomcat standalone has zero facilities to support this. For example, it basically ignores ejb-ref entries in your deployment descriptor. There are three feasible approaches: * Use a non-standard JNDI initial context, configured in a way that will talk to your particular EJB server. The details of this are very EJB-container-specific (the TOMCAT-USER archives have comments from people who've been able to do it from Tomcat to the J2EE RI), and is not guaranteed to be available. You're also going to have to piece together the right classes for your particular app server in order to make the right stuff available. * Use a EJB+Servlet container that has Tomcat integrated in (such as the J2EE RI or JBoss). The container provider has solved all these problems for you already. * Use the servlet container provided by your EJB container vendor (sounds like WebLogic in your case), which also has solved all these problems. Anything else is way out on the fringes of technical fragility, and probably relies on internal APIs that are subject to change. That's why you have so many problems in each upgrade cycle -- you're trying to do something very much non-mainstream. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Should I understand this all to say that Tomcat is not at all J2EE 1.3 compliant? Section 6.1.2 states that a compliant web container supports EJB client API's! Section 6.4 states that a container that supports the EJB client API's must also support interoperability requirements. Section 6.11 states a container must support JAXP, including one SAX2 parser, one DOM 2 parser and one transformer. Figure 2.1 Strongly implies that our architectural assumption (web containter talking to EJB container) is a valid one. I still vote for quite confusing and somewhat misleading -Original Message- From: Andrew Gilbert Sent: Thursday, October 10, 2002 3:39 PM To: Tomcat Users List Cc: 'Craig R. McClanahan'; 'Jean-Francois Arcand'; 'Shapira, Yoav'; Tim Segall Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... Craig, I was slowly coming to the conclusion that approaches 2 and 3 are superior. Having said that, I am still somewhat bothered. It is easy to (naively?) adopt approach 1. The two prior responses seemed to indicate this approach was okay. Yoav is using it. And there is currently another active thread on this list about using Tomcat to talk with JBoss. There is certainly strong natural motivation to want to deploy servlet container(s) toward the edge talking to app server(s) at the core. Seems odd to assert I should only talk to my distributed remote object server by first putting myself inside another distributed remote object server. Anyway, I appreciate your response. Thanks. Andy -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 12:56 PM To: Tomcat Users List Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... On Thu, 10 Oct 2002, Andrew Gilbert wrote: Date: Thu, 10 Oct 2002 11:42:05 -0400 From: Andrew Gilbert [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... Yoav and JeanFrancios, Thank you both for your replies. They were helpful and somewhat reassuring. At the general level: We are aware that Tomcat is not a full J2EE container. But servlets calling EJB's is bread and butter stuff. Only for an EJB server :-). Tomcat standalone has zero facilities to support this. For example, it basically ignores ejb-ref entries in your deployment descriptor. There are three feasible approaches: * Use a non-standard JNDI initial context, configured in a way that will talk to your particular EJB server. The details of this are very EJB-container-specific (the TOMCAT-USER archives have comments from people who've been able to do it from Tomcat to the J2EE RI), and is not guaranteed to be available. You're also going to have to piece together the right classes for your particular app server in order to make the right stuff available. * Use a EJB+Servlet container that has Tomcat integrated in (such as the J2EE RI or JBoss). The container provider has solved all these problems for you already. * Use the servlet container provided by your EJB container vendor (sounds like WebLogic in your case), which also has solved all these problems. Anything else is way out on the fringes of technical fragility, and probably relies on internal APIs that are subject to change. That's why you have so many problems in each upgrade cycle -- you're trying to do something very much non-mainstream. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
Doh! Thanks again for the replies. I appreciate the input. The path is at least becoming clearer now... -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 4:31 PM To: Tomcat Users List Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... On Thu, 10 Oct 2002, Andrew Gilbert wrote: Date: Thu, 10 Oct 2002 16:23:21 -0400 From: Andrew Gilbert [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations... Should I understand this all to say that Tomcat is not at all J2EE 1.3 compliant? That's a fair one-liner summary. The more correct answer is that Tomcat complies with all of the mandatory Servlet 2.3 and JSP 1.2 features, plus *some* of those that are only required by a complete J2EE platform (i.e. the JNDI naming context, and availability of a JDBC data source accessed via an API compatible with J2EE standards). It has no support for EJB, JMS, ... so it is absolutely not a J2EE compliant server by itself. Nobody eer claimed it was (although I can't help it when people make assumptions). What makes more confusing is that several people bundle Tomcat into a complete J2EE-ish thing. Sun does that with the J2EE RI, for example -- but it's only a J2EE platform when you use all of it. But Tomcat by itself is not a J2EE container. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Classpath Issues, Tomcat 4.X and J2EE Interoperability frustrations...
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]
No MBean for mod_jk, only mod_jk2 in Tomcat 4.1.12?
Will ask this again in different manner. Looks like there is no MBean support in 4.1.12 for the AJP13 (mod_jk) Apache connector. Is there any easy way to remedy this, short of disabling JMX support? Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Reminder for others upgrading to 4.1.12...
In the process of trying to upgrade our existing application from 3.3 to 4.1.12 I suffered some pain by not reading the release notes. Reminder to others who try: The invoker servlet is commented out by default in TOMCAT_HOME/conf/web.xml. If you don't have servlet mappings in your WEB-INF/web.xml or don't map the invoker servlet either globally or locally, trying to figure out what is going wrong with servlet mappings will waste a lot of your time. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 - AJP13 mod_jk MBean Error
Anyway, short of disabling JMX support, of dealing with the following when trying to use mod_jk (versus mod_jk2) under 4.1.12? ServerLifecycleListener: createMBeans: MBeanException java.lang.Exception: ManagedBean is not found with Ajp13Connector at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225 ) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(Serve rLifecycleListener.java:369) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(Serve rLifecycleListener.java:777) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Servlet basic question...classpaths and servlet locations.
The documentation in 3.3 on classpaths is quite good, with an excellent graphic describing classloaders and how/where things get loaded. http://localhost:8080/doc/tomcat-ug.html#configuring_classes Would also suggest familiarity with the Servlet and JSP specs (ie, an understanding of WEB-INF/lib and WEB-INF/classes) Hope this helps. -Original Message- From: Neale, Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 7:42 AM To: '[EMAIL PROTECTED]' Subject: Servlet basic question...classpaths and servlet locations. I have Apache 1.3 and Tomcat 3.3 installed. I'm using Tomcat to run servlets, having used JSERV in the past. My question is, how does tomcat decide where to look for the class to run? Secondly, if it runs the class, how can I set the classpath for it? With JServ it was easy. I set lots of wrapper.classpaths in jserv.conf and any request received by Apache that had /servlet in it was directed at JServ. I've read the Tomcat docs but couldn't understand it. What I'm looking for is a step by step guide for taking a class, lets call it LN.class, and being able to call it fron a browser by http://localhost/.../LN I can get the examples working e.g http://localhost/examples/servlet/SessionExample that is in the webapps\examples\web-inf\classes directory. How can I implement my LN class? The LN class will run if I put it under the Root\web-inf\classes directory but then complains that it can't find another class that it uses that should be in the classpath (but isn't because I don't know how to set it. -- The content of this e-mail is confidential, may contain privileged material and is intended solely for the recipient(s) named above. If you receive this in error, please notify Software AG immediately and delete this e-mail. Software AG (UK) Limited Registered in England Wales 1310740 Registered Office: Hudson House, Hudson Way, Pride Park, Derby DE24 8HS -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Anyone ever respond to this - RemoteRuntimeException under tomcat3.3 WL 6.1
Picked this up from the archive for the list and curious if anyone has responded to it. We see the same thing. Under Tomcat 3.3 with WL 5.1 we get a partial stack trace on the console of Tomcat anytime an app level exception comes back over the wire, using WL 6.1 it gets worse than that and the http request fails back to the end user. Exceptions being thrown extend either Exception of Finder/Create, and are not EJB exceptions. Original Post From: Dan Lipofsky Subject: RemoteRuntimeException Date: Mon, 24 Dec 2001 09:08:32 -0800 I have this problem in tomcat-3.3 but not in tomcat-3.2.4. I am using tomcat for JSP and weblogic server 6.1 for EJB. The EJB throws an exception like com.mycompany.FoobarException but it shows up in my JSP page nested inside a weblogic.rmi.extensions.RemoteRuntimeException. I am using the same weblogic install in both cases so I doubt it is weblogic's fault. Is this a bug in tomcat-3.3? Or something else? Thanks, Dan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Issues with class loaders and jsp:include in Tomcat 3.3
We are using Tomcat 3.3 Final. Having a curious problem on certain jsp pages that try to dynamically load classes located in a jar in the WEB-INF/lib area of the web application. The apparent differential is the use of jsp:include tags within the page. The details are as follows: Using Weblogic 5.1 sp9 trying to a do a naming lookup inside a tag. If the page containing the tag also has a jsp:include then the lookup fails. Get a class not def error when trying to setup the initial context, cannot find weblogic.jndi.WLInitialContextFactory. This class in located in a jar in WEB-INF/lib. If the jsp:include is removed from the page the class is found and the naming lookup succeeds. Also, if the class has already been loaded within the app, by another page without a jsp:include or by a servlet, then pages with the jsp:include will work. Ie, this only seems to be a problem with the initial load of the class by the web application class loader in combination with the include tag. Only diffs in the generated page code are the expected pageContext.include pieces. I would guess the problem lays somewhere in that direction. Using a static include directive vs the include tag does make the problem go away and may be our workaround for now. However, would prefer to use the tag. Would appreciate any insight. Thanks. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.2, RMI, JNDI Classloaders: a solution
Carlos, Thanks. This is interesting. Can you explain what the effect of Thread.setContextClassLoader() is? Does it make classes from the WEB-INF/lib and WEB-INF/classes area avaiable to classes loaded by the boot class or system class loader? Andrew -Original Message- From: Carlos Pita [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 15, 2001 3:50 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Tomcat 3.2, RMI, JNDI Classloaders: a solution Hi all! A lot of people has been having problems with Tomcat 3.2, classloaders, jndi, jndi.properties, rmi and stubs when trying to call ejbs from Tomcat in a different JVM. The problem is simple: because jndi and rmi classes are loaded by the system (or bootstrap, I can't remember it but it really doesn't matters) classloader -see jdk1.3\docs\tooldocs\findingclasses.html - they can not see the resources and classes of your context (loaded by the context classloader, which is a descendant -i mean in the classloader delegation hierarchy- of the system classloader). An obvious and bad solution is to put your classes in the CLASSPATH (don't do this!) to allow them to be loaded once for all of your contexts by the system classloader. Instead, to fix the problem you should add the request interceptor showed below to your server.xml (I have read an email saying that it should be the last request interceptor in the chain so I put it the last, but I haven't tried with another combinations): RequestInterceptor className="org.apache.tomcat.request.Jdk12Interceptor" / This is in order to call the Thread.setContextClassLoader() during each request. The following is taken from a post by C. McClanahan in tomcat-user: "Note that Tomcat 4.0, because it is guaranteed a Java2 platform as a prerequisite, calls Thread.setContextClassLoader() on every request by default". But even after doing this, jndi.properties in your WEB-INF/classes (or in a .jar in WEB-INF/lib) won't be loaded. Keep reading the following paragraphs quoted from an email by Christopher Audley in tomcat-dev! "" The following discussion applies to tomcat 3.2.1 running under Sun JDK 1.3 I spent this afternoon tracking down why a call to new InitialContext() from a web application did not appear to be finding the jndi.properties located under WEB-INF/classes. I am using the Jdk12Interceptor and verified that Thread.currentThread().getClassLoader() was the tomcat AdaptiveClassLoader before the call to new InitialContext(). After some investigation I determined that the JNDI implementation uses the classloader method getResources to find all occurances of the file jndi.properties in the classpath. AdaptiveClassLoader does not have this method implemented, the default implementation calls findResources which simply returns an empty Enumeration unless overriden. Attached are patches to AdaptiveClassLoader and ClassRepository to implement findResources so that JNDI will behave correctly when a jndi.properties is placed in the web application classpath. I have moved some code from AdaptiveClassLoader to ClassRepository to avoid code duplication and changed the implementation of getResource to findResource for consistency. I hope that this can be incorporated into the sources before 3.2.2. "" Finally, after aplying the patch (I've attached it as you can see) and recompiling the sources you get the desired behaviour. See you, Carlos
RE: Tomcat 3.2, RMI, JNDI Classloaders: a solution
You can make them visible, but the class from the boot classloader or system classloader has to know what to do -- it calls Thread.getContextClassLoader() to get the class loader for the current thread, and asks *that* classloader to create the new object, instead of using the "new" operator. As an example then, Toolkit.getDefaultToolkit() does a Class.forName and if that fails tries the system class loader when creating the default AWT toolkit. I would assume then that the jdk12 interceptor is not going to help in a scenario such as using PJA where one has to force pja.jar into the boot class path. Is that correct?
RE: Classpath/loader problems internal to tomcat 3.2.1 [Fwd: RMI and Tomcat]
Gerard, Not sure if you saw the exchange between David and Craig McClanahan on Sunday. Craig provided a lot of helpful information on class loading. David had a clever work around for at least one of the issues likely to be encountered, basically hooking the appropriate javax.* class to use a servlet implemented factory, thus eliminating some of the class not found issues. Hope this helps, Andrew -Original Message- From: Gerard BORREILL [mailto:[EMAIL PROTECTED]] Sent: Monday, March 12, 2001 4:59 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Classpath/loader problems internal to tomcat 3.2.1 [Fwd: RMI and Tomcat] Hello, Thank you very much David Wall and Andrew Gilbert for your answer. Well I would really like that the way how class loading should work in Tomcat, works this way. I am using 3.2.1. I am using Jeremie that is a RMI like protocol over IIOP, and so implicitely the RMIClassLoader (it has only static methods: it delegates class loading to the right class loader so this should not generate any problem). My servlet is using Jeremie to communicate with a server. If performed as a non-servlet client it works fine, but if performed as a servlet, my Jeremie classes are not found: Class not found: org.objectweb.jeremie.libs.stub_factories.std.OptStub In fact the first Jeremie class used that is searched is not found. I have under the WEB-INF/lib directory of my web application: myProject.jar Jonathan.jar (that contains Jeremie: Jeremie is a sub project of Jonathan). I do not want to put the Jonathan.jar in another place for security reasons. Who can help me ? Is my problem due to a misconfiguration in a configuration file of Tomcat ? Do I have to add a line ? I have found nothing in the configuration files about this. Is anyone using several .jar files in WEB-INF/lib ? Suppose RMIClassLoader does not use the right class loader? (I do not think at all this is the bug). How can I get a reference to the right classloader ? In advance thank you, Grard, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Classpath/loader problems for JNDI/JMS with JSP
Good thread. This is an extremely frustrating issue. As is apparent from
this dicussion, other threads, and our own experience, it is not easy or
pretty integrating the latest stable Tomcat (3.2.1) into a full J2EE
environment.
I am going to give the solution suggested below a try in our environment
with 3.2.1 and see how much farther we get.
Thanks again.
-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 11, 2001 12:33 AM
To: [EMAIL PROTECTED]
Subject: Classpath/loader problems for JNDI/JMS with JSP
With JMS, you use the JNDI InitialContext object that includes the class
name of the provider of the JMS. Then, JNDI uses that to instantiate the
class and create the initial connection for JNDI queries.
Do you have any idea how to work with this in a Tomcat world? I'm not
sure
how to cause this to load since I think it's that nasty situation in which
a
lower-level classloader doesn't know how to move up. In this case, do you
think it's "okay" to put the JMS classes in the CLASSPATH for Tomcat? I've
seen that it will work.
Unfortunately, this causes the entire problem to rear its ugly head again.
The problem is that I have classes that are in the WEB-INF paths for Tomcat,
and one of those classes is sent as a Serialized object through JMS. And
since JMS ends up being loaded by the CLASSPATH classloader, it cannot find
the class my JSP created.
It seems like using JNDI and JMS in JSP/servlets was supposed to work since
they are part of the J2EE world. Didn't anybody realize that they'd run
into these odd classloader issues? I was able to make it work (I think)
using this code which basically overrides the default JNDI initial context
factory builder and does my own. I have no idea if this will work for other
JMS/JNDI systems.
// First, trick JNDI into use my context factory builder...
javax.naming.spi.NamingManager.setInitialContextFactoryBuilder(this);
And because I was lazy, I just made my class implement:
javax.naming.spi.InitialContextFactoryBuilder
And here's the code that implements that interface:
public javax.naming.spi.InitialContextFactory
createInitialContextFactory(Hashtable env)
throws
javax.naming.NamingException
{
String initialContextFactory =
(String)env.get(Context.INITIAL_CONTEXT_FACTORY);
try
{
return
(javax.naming.spi.InitialContextFactory)Class.forName(initialContextFactory)
.newInstance();
}
catch(java.lang.InstantiationException e)
{
throw new javax.naming.NamingException("Could not instantiate: " +
initialContextFactory);
}
catch(java.lang.IllegalAccessException e)
{
throw new javax.naming.NamingException("Could not legally
instantiate: " + initialContextFactory);
}
catch(java.lang.ClassNotFoundException e)
{
throw new javax.naming.NamingException("Could not load: " +
initialContextFactory);
}
}
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: RMI and Tomcat
I have made two posts to the list about similar problems with 3.2.1 and using JNDI/RMI (EJB's) and not figured much out. Not having the time to delve further I backed off to Tomcat 3.1. You may try that for the interim. Any feedback from any of the implementors that would help us start to figure this out? -Original Message- From: Gerard BORREILL [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 12:01 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RMI and Tomcat Hello, Sorry, but I have not found any answer in the mailing list archive. I am using Tomcat 3.2.1. I have a web application based on servlets that communicates with a server using RMI, so I have set the SecurityManager when starting Tomcat. I get a java.lang.ClassNotFoundException on a class that is under the WEB-INF/classes/ directory, or in *.jar file located in WEB-INF/lib. The class file is at the right place. I have made two attempts: 1) put every classes in jar files. I have 2 jar files. myApplication.jar and com.jar. The class not found is in the com.jar, and the servlet class is in the myApplication.jar file. 2) expand those .jar files under WEB-INF/classes, The class file not found is not in the same package as the servlet class. (com.xxx and fr.xxx.). I do not understand why tomcat is not able to find this class. I have no SecurityException.Why is it finding my servlet and performing it, and not my com.xx classes. I think it is a matter of class loader (?) How can I know the class loader used by tomcat for my application ? Do I need this ? Does anyone have a solution ? In advance thank you. Grard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Can't migrate to 3.2.1 - Number of issues
There seem to be a number of issues with 3.2.1, some of which prevent us from moving to it. Looking for any insight into workarounds, fixes, or strategy (ie wait till 3.3?). From perusing the list, we don't seem to be alone in experiencing these. Unfortunately, I haven't gotten a feel for workarounds or fixes for all of them. Maybe my lack of clue, don't know. Ultimately need to run a production stable environment, so I assume 3.3 and 4.0 are out for now. We truly appreciate the product and work of everyone involved, want to be able to stay current. Thanks. Environment: Apache 1.3.12 Tomcat 3.2.1 (from Tomcat 3.1) Linux RH 6.2 Sun JDK 1.3 Weblogic 510sp8 on Solaris host Problems: 1. ClassNotFoundException trying to connect to a J2EE container (Weblogic) naming directory. Approriate jars are in WEB-INF/lib, works under 3.1. Stack trace included at end of message. Moving jars to CLASSPATH fixes this, but leads to problem number 2. (And it is annoying to have to do this - as complicates management of development, testing, staging and production environments). 2. ClassCastException trying to invoke RMI object (now that we can contact directory, trying to load a Session EJB). No clue how to fix. Stack dump included at end of message. 3. Use of AJP13 leading to Internal Server Errors. Annoying, but problem not a production barrier. 4. Use of AJP13 breaks multipart uploads. (We haven't seen this yet but do rely on multipart uploads for our application, seem to be a lot of posts about this). /**/ 2001-03-06 04:54:55 - Ctx( /account ): Exception in: R( /account + /servlet/login + null) - javax.naming.NoInitialContextException: Cannot instantiate class: weblogic.jndi.WLInitialContextFactory. Root exception is java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:45) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:655) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246) at javax.naming.InitialContext.init(InitialContext.java:222) at javax.naming.InitialContext.init(InitialContext.java:198) at COM.soundbite.web.account.src.LoginServlet.getInitialContext(LoginServlet.ja va:376) at COM.soundbite.web.account.src.LoginServlet.lookupHome(LoginServlet.java:354) at COM.soundbite.web.account.src.LoginServlet.validateParams(LoginServlet.java: 284) at COM.soundbite.web.account.src.LoginServlet.doPost(LoginServlet.java:189) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection (Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) // java.lang.ClassCastException at weblogic.iiop.PortableRemoteObjectDelegateImpl.narrow(PortableRemoteObjectDe legateImpl.java:94) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137) at COM.soundbite.util.EJBUtil.lookupHome(EJBUtil.java:73) at COM.soundbite.web.account.src.LoginServlet.validateParams(LoginServlet.java: 279) at COM.soundbite.web.account.src.LoginServlet.doPost(LoginServlet.java:184) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at
RE: Can't migrate to 3.2.1 - Number of issues
Chris, Thanks for the suggestion. Unfortunately, not a practical option. We are already deployed and running under WL, would be a major political undertaking to fix that. Previous post from Randy L would also suggest that JBoss integration may have similar issues. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Albert Sent: Wednesday, March 07, 2001 12:39 PM To: [EMAIL PROTECTED] Subject: Re: Can't migrate to 3.2.1 - Number of issues Andrew, It seems that Tomcat/WL integration is the problem here. Have you thought about checking out Jboss? It has embedded tomcat 3.2.1 support (tomcat runs in same VM), it's open source , and supported by a very active and dynamic group of developpers. Chris Andrew Gilbert wrote: There seem to be a number of issues with 3.2.1, some of which prevent us from moving to it. Looking for any insight into workarounds, fixes, or strategy (ie wait till 3.3?). From perusing the list, we don't seem to be alone in experiencing these. Unfortunately, I haven't gotten a feel for workarounds or fixes for all of them. Maybe my lack of clue, don't know. Ultimately need to run a production stable environment, so I assume 3.3 and 4.0 are out for now. We truly appreciate the product and work of everyone involved, want to be able to stay current. Thanks. Environment: Apache 1.3.12 Tomcat 3.2.1 (from Tomcat 3.1) Linux RH 6.2 Sun JDK 1.3 Weblogic 510sp8 on Solaris host Problems: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Migration to Tomcat 3.2.1 Classpath errors using Weblogic 510
We are in the process of upgrading to Tomcat 3.2.1 from 3.1 and have experienced an issue with class loading which we did not see before. We started getting class not found exceptions while trying to do a naming lookup to a Weblogic 510 sp8 server. Under 3.1 this was not an issue. We placed the weblogic .jar files in our WEB-INF/lib dir and everything was groovy. Setting the classpath upon startup of tomcat seems to fix the problem on Windows 2000. However, doing so on Linux (RH 6.2) results in Class Cast exceptions which we do not see with Tomcat 3.1 against the same deployed code base. Anyone help or pointers are appreciated. Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Session beans and multiple tomcat servers ?
One option is a load balancer that will handle session affinity, either on it's own or through a custom cookie/url rewrite. This is a problem with almost all web application server solutions, certainly not unique to Tomcat/JSP. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Peterson Sent: Friday, March 02, 2001 5:05 AM To: [EMAIL PROTECTED] Subject: Session beans and multiple tomcat servers ? Hi Everybody, I have a question about the architecture of tomcat and the sharing of beans (typically accessed by JSP page code) with a scope of "session". It seems to me that one major problem with JSP and session-scoped beans on tomcat (and possibly other servlet engines ? i'm not trying to bag tomcat specifically here !) is that I am restricted to a hardware architecture of a *single webserver* running tomcat. If I wish to run a 'load-balanced' (dns round robin most likely) server configuration with multiple instances of tomcat sitting behind the same URL, is there any known way in which to share session-scope java beans created by one tomcat server across the other servers ? The only way I can see to solve this problem is to push all session information to a backend database accessible by all the webservers, and to look up the session information from the database *each* time the user moves from page to page (and potentially across tomcat servers). This seems kludgy, and the database access requirements defeat both the simplicity of the session-bean approach, and add overhead to the very scalability and performance that you're trying to achieve by using multiple servers. Any guidance or relevent experiences much appreciated ... Thanks in advance. David Peterson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
