I have two Web applications A and B. The user login is handled by the Web Application A and keeps some values in HttpSession. can Web App B access the session variable set by Web App A? I am using Weblgic Server 6.0.
thanks in Adv,
Assuming WebLogic 6.0 is compliant to the Servlet 2.3 spec, the answer is "no". From the spec:
SRV.7.3 Session Scope
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
This is further reinforced by:
SRV.9.2 Relationship to ServletContext
The servlet container must enforce a one to one correspondence between a web application and a ServletContext. A ServletContext object provides a servlet with its view of the application.
In order to share data across web applications you'll need to implement your own scheme. If it's a small amount of data, you could store it in a cookie that either web application could retrieve. If it's a large amount of data, you could store it in a database, then set a token in a cookie to identify the client and retrieve the data.
New Atlanta Communications, LLC
Instead of using Cookoes is it possible to do as following?
In the above example call Servlet in WEb App 'A' and forward the request to the Web App 'B' and continue the process.
HttpRequest can carry/offer only name value pairs. If you want the login info to be carried from one application to another then you can place the credentials (authentication flag / token etc.,) as name value pairs in the request object and either post it to the second application from the first or get it in the second application from the first. Just remember that even within the same application when you pass HttpRequest, it would only have "references" to the objects in the session.
If your application demands more information to be passed from one app to another, you can work around this constraint by actually serializing your login object and setting the entire serialized stream as a value for a name in the request and passing it over to the second app. You can deserialize the object in the second application. This would add a lot of overhead along with security risks and is not usually suggested as long as you have other means available. Even storing the info to an intermediate database would be efficient than passing large serialized objects in request as name value pairs.
Whatever happened to my manners. :-)
I fogot to mention "Hope that helps" in the above reply.