This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Different web apps are usually loaded using different ClassLoaders, which means that static fields will not be the same across applications. The servlet spec also has no provisions for sharing data between web apps; they are meant to be separate. You could use a shared database, of course.
... and pass it as an attribute of the request to the other.
You cannot pass(or forward) a request attribute from one web app to another. You could however send a parameter and use response.sendRedirect to get it across to the second app.
Using a shared cache is what I would recommend.
SCJP 1.4, SCWCD 1.4
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler et al, Refactoring: Improving the Design of Existing Code, 1999
You will probably need to relax the settings for your app server to do this. With Tomcat it's done via the "crossContext" attribute of the Contex attribute in server.xml (or in the context xml fragment file).
Yes, I have tried this, works fine. I don't see why it wouldn't. A HttpRequest is a HttpRequest, and you can add attributes to it. Simple as that, as far as I know it has the same functionality no matter where you forward it to. I'm not sure about the crossContext thingy Ben mentions, at work I am not the one who configures the servers.
Joined: Jul 27, 2005
originally posted by Iris Hoekstra A HttpRequest is a HttpRequest, and you can add attributes to it....I'm not sure about the crossContext thingy Ben mentions, at work I am not the one who configures the servers.
I maintain you cannot forward request objects across two servlet contexts(web apps)...
unless of course you set the crossContext attribute like Ben stated above.
Technically you can share objects between different web applications in most cases if the web applications are packaged within the same ear on your application server. There would have to be some sort of intermediary object/mechanism.
Keep in mind this is somewhat app server dependent, but something like the following would work, even though I should add I wouldn't necessarily do it. If I wanted to keep track of the total number of hits between multiple webapps in the same ear, I might have a class with a static variable hits:
Now if we included this class in each WAR, it won't work as intended. Each WAR has its own classloader so basically each webapp will have its own hit counter and won't be recording or accessing hit counts from the other webapps. If however you package the class in a JAR which is packaged in the ear, and you set the Manifest of each WAR to include that JAR in its classpath, then the HitCounter will work as intended, since the JAR's classloader will be a parent to the WAR classloaders.
When app servers try to load a class, they typically first try to load it using the classloader's parent classloader. So when webapp A accesses HitCounter, it will first try to load it using its parent classloader, which is the classloader that would load the jar. When webapp B accesses HitCounter it will first try to load it using the parent to the classloader for webapp B, which is the classloader for the jar and is the same classloader that webapp A used to load HitCounter, which allows it to work as intended.
This isn't clean or even something you necessarily should do, but it will work in most circumstances. I guess the bottom line is that you can't share data without using an intermediary, be it something like the example above, going through RMI and JNDI, a session bean, a cookie, or whatever. [ August 25, 2005: Message edited by: Jason Menard ]
Tomcat doesn't recognize ear files but you can achieve the exact same results by putting the static variable in a class who's file is located in TOMCAT/common/classes or jared and put into TOMCAT/common/lib.
Or TOMCAT/shared/classes, TOMCAT/shared/lib respectively.
As Jason said, it's not a clean solution. The servlet spec came out with the notion of self contained web applications in servlet spec 2.2. Ignore this principal at your own peril.