Problem: using Bean defined as scoped-proxy

[spring_usr]

Hello,

Im programming a Webapplication using Jsf and Spring ...
I defined my Beans for Test in the following way:
<bean class="com.TestBean"
name="testBean" scope="session">
<aop:scoped-proxy/>

<property name="testProperty" >
<ref bean="testPropertySpec" />
</property>
</bean>

<bean id="testPropertySpec" class="com.TestProperty" >
</bean>
I think refered to the Spring 2.0.6 documentation this is correctly.
My purpose of using session is to set some user specific Properties for the Session. This I make depending on the first Request:

public void doTest(ServletRequest request){
WebApplicationContext context = org.springframework.web.context.support.
WebApplicationContextUtils.getRequiredWebApplicati onContext( ((HttpServletRequest)request).getSession().getServ letContext());

com.TestBean testBean = (com.TestBean) context.getBean("testBean");

com.TestProperty prop = (com.TestProperty) context.getBean("testPropertySpec");

testBean.setTestProperty(prop);
}

The Problem is that:
testBean.setTestProperty(prop);
creates a new instance of my TestBean Object and not use the once created on startup and getted in line: com.TestBean testBean = (com.TestBean) context.getBean("testBean"); . If i use the TestBean in the Application the setted Value (prop) is not in the TestBean. -> logical because the setter was invoked on the new Instance of TestBean.
But why Spring creates a new instance in my Case. I defined TestBean on session Scope and call a Method on this Object. If I had understand it correctly the call of setTestProperty should not create a new object an call this method on that Object.
Any Ideas?

[Jörg Heinicke]

The Problem is ...

Your problem description would mean that in

com.TestBean testBean = (com.TestBean) context.getBean("testBean");
Object testProperty = testBean.getTestProperty();

testProperty is null, wouldn't it? That would indeed be very strange since you get a somehow invalid object. Where exactly do you get from that context.getBean("testBean") returns another instance of TestBean than it is accessed with testBean.setProperty(prop). How do you check that

If i use the TestBean in the Application the setted Value (prop) is not in the TestBean.

Jörg

[spring_usr]

Not testProperty isn't null.
TestBean and it's TestProperty Object are initialized at Server startup.

TestBean: ObjectId=65
TestProperty: ObjectId=179
Both ObjectId's from the Eclipse Debuger (Breakpoint in the Constructors)

now the Instruction:
testBean.getTestProperty();

The next step is that the Eclipse jump into the Constructor Breakpoint of
TestBean.
TestBean: ObjectId=180
TestProperty: null

now in my TestBean Object is the new Constucte Object
TestBean: ObjectId=180
TestProperty: ObjectId=179
and on this TestBean Object the method getTestProperty(); is called.

You can see my Problem is, that the TestBean Object i go on startup gets switched if i call a Method of it.

To your secound Question: I see that in the Eclipse Debuger.

[spring_usr]

I found a solution for the Problem.

In the Session is as Attribute scopedTarget.testBean the second TestBean instance (in last Post id: 180) after calling the Method testBean.getTestProperty(); as described before.

On the further calls to the Methods of testBean ebverithin works fine.

So my solution is:

if(((HttpServletRequest)request).getSession().getA ttribute("scopedTarget.testBean") == null){
com.TestBean testBean = (com.TestBean) context.getBean("testBean");
testBean.getTestProperty();
}

com.TestBean testBean = (com.TestBean)((HttpServletRequest)request).getSes sion().getAttribute("scopedTarget.testBean");

com.TestProperty prop = (com.TestProperty)
context.getBean("testPropertySpec");


testBean.setTestProperty(prop);


I don't know why I must call the Method testBean.getTestProperty(); before the scoped Proxy Object is in the scope, but this solution works fine.

[Jörg Heinicke]

Both ObjectId's from the Eclipse Debuger (Breakpoint in the Constructors)

Be careful, you might be fooled by the debugger. Since the scoped proxies work with ThreadLocals the Eclipse debugger might see its "own" instance since it is not running in the same thread as the session the object actually belongs to.

Jörg