Originally posted by Jagmohan Negi:
can i have the code example for that
Could you please try to do something on your own. You have got the ideas. Now just try to implement that. Having a shared DB is an easy option. Where is the problem??
Lets get your hands dirty with the code. We will here to help you in getting a clean code.
[ August 24, 2005: Message edited by: Adeel Ansari ]
... 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.
With Tomcat it's done via the "crossContext" attribute of the Contex attribute in server.xml (or in the context xml fragment file).
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.
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 ]
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.