Same bean id in different wars in same JVM

[A Kumar]

Thus, when coming into your application via http OR https, you end up using an instance of this ProductController class. It does not, however, mean that it is the same instance somehow shared across webapps as you alluded to earlier. It simply means that you have two objects of the same type, one in each container.

I hope I haven't missed something - does this help clear the issue up for you? If it does not, what is the actual problem you're experiencing? i.e.: why is this behavior an issue for you?

I agree that there should be 2 objects of same type in each within its own app class loader

But the problem i face is....

When i hit the http

it goes through the NonSecureMapping bean and gets the products bean instance of http

And when i hit the https

it goes through the SecureMapping bean and
gets the products bean instance of http it is getting routed to the http bean.....

The classloader policy for both the app is parent_last in WAS 5.1

Regards

[Chris Beams]

I've asked some other folks to take a look at this thread. Unfortunately, it's not clear to me what's happening here. Stay tuned for further responses.

One question in the meantime: How do you know that the 'products' bean you get when hitting https is the bean that was configured in the http war's container? Given that the 'products' bean in both the http and https containers are instances of the same class, I'm interested to see how you're certain that you're hitting the one that was configured in the http container.

[A Kumar]

I had put the System.out.pritnln statements in handleRequest method of both the controller beans...

in http version.... " In HTTP BEAN instance "
in https version.... " In HTTPS BEAN instance "


Also System.out.pritnln statements in the SecureMapping and NonSecureMapping beans


So when i hit https...it goes through SecureMapping though ...(figured it SOP statements )

then comes to the http product instance

and in console....it prints " In HTTP BEAN instance "


Both the wars are embedded in a single ear

Regards

[Mike Bingham]

Just to clarify, are all of your application bean classes local to each web app (i.e., in WEB-INF/classes or WEB-INF/lib), or do you have some/all deployed at the ear level?

It might be helpful to gather more info about which classloader is being used to load your bean classes. I believe that WAS has a classloader viewer utility which can help with this. See here for more details:

http://www.redbooks.ibm.com/redpapers/pdfs/redp4307.pdf

I assume your preference is to have a distinct application context for each web app with separate bean instances, but if you are instead interested in having instances of common beans shared between the web apps, you might take a look at this option:

http://blog.interface21.com/main/200...g-application/

[A Kumar]

Just to clarify, are all of your application bean classes local to each web app (i.e., in WEB-INF/classes or WEB-INF/lib), or do you have some/all deployed at the ear level?

classes are local to each ...war....but they have the same names
and the bean ids are same in the config files across the wars

It might be helpful to gather more info about which classloader is being used to load your bean classes. I believe that WAS has a classloader viewer utility which can help with this. See here for more details:

http://www.redbooks.ibm.com/redpapers/pdfs/redp4307.pdf

I will have a look at this...

I assume your preference is to have a distinct application context for each web app with separate bean instances

Yes....

[Mike Bingham]

Another link which might be helpful in further debugging this issue:

http://www.ibm.com/developerworks/we...406_brown.html

Additional information from the WAS classloader viewer utility or the classpath debugging servlet described in the link above would be useful in trying to narrow down the cause of the problem.

[A Kumar]

Hi,

The classloader policy is parent_last...

Regards