Can two different web application share a variable

[Jagmohan Negi]

Can two different web application share a variable with the help of Servlets or JSPs

[Daniel Rhoades]

Using JNDI + RMI you can access objects in other apps, a stateless session bean might work well for you.

[Ulf Dittmer]

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.

[Jagmohan Negi]

can i have the code example for that

[Adeel Ansari]

Originally posted by Jagmohan Negi:
can i have the code example for that

No.

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.

Thanks.
[ August 24, 2005: Message edited by: Adeel Ansari ]

[Vicky Pandya]

or you can use shared cache or messaging is also an option.

[Iris Hoekstra]

You can fire requests from one webapp to another. You might define the variable in one webapp and pass it as an attribute of the request to the other.

[Ola Daniel]

... 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.

[lexander Bosco]

just like OLA has said response.sendRedirect() should do what u want.

[Iris Hoekstra]

Originally posted by Ola Daniel:
[QB]
You cannot pass(or forward) a request attribute from one web app to another.

Yes, you can. For example, in the doGet or doPost of a servlet in app A you might do:

  public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    String foo = "hello";
    request.setAttribute("importantString", foo);
    RequestDispatcher dispatcher = getServletContext().getContext("/appB").getRequestDispatcher("/some_path");
    try {
      dispatcher.forward(request, response);
 

[lexander Bosco]

Iris have u actually tried this?

[Ben Souther]

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).

http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html

[Iris Hoekstra]

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.

[Ola Daniel]

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.

[Jason Menard]

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:

public class HitCounter {
  private static int hits;
  public static synchronized int getHits() { return hits; }
  public static synchronized void addHit() {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 ]

[Ben Souther]

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.

[D Rog]

If I were you, then I used a cookie for this purpose.