Controller-Design doubt

[A Kumar]

Hi,

I have a doubt about the controller...

I have a controller class defined in the .xml (its a singleton)

In the controller ,we instantiate another class and this delegated class actually does the main work..

can we define that spring injects this delegated class into the controller...

If yes,then isnt controller(singleton="true") a thread safe instance...and then how can spring inject the delegated class(if it is declared as a bean) for each request???


Thanks in advance,
A Kumar

[Jörg Heinicke]

In the controller ,we instantiate another class and this delegated class actually does the main work..

can we define that spring injects this delegated class into the controller...

If yes,then isnt controller(singleton="true") a thread safe instance...and then how can spring inject the delegated class(if it is declared as a bean) for each request???

Does this imply the class doing the actual work is state-full or more general a prototype (created on each request)? Then you can set it up exactly like this. Make it a request-scoped bean in the XML config, inject a proxy into the controller.

Jörg

[A Kumar]

Yes its a stateful ...object...

How can we "Make it a request-scoped bean in the XML config"?

A sample conf would be helpful;I amusing spring 1.2.8


Regards

[Jörg Heinicke]

How can we "Make it a request-scoped bean in the XML config"? I amusing spring 1.2.8

Problem :( Bean scopes other than singleton and prototype are only possible in Spring 2.0. Actually request scope is very similar to thread scope. So doing something yourself using the ThreadLocalTargetSource might be not that difficult. Unfortunately I have no sample code. If nobody else can provide something like this you will be on your own.

Jörg

[A Kumar]

Thanks Jörg!!

A sample code would have been handy to start off ...:(

[Jörg Heinicke]

Try to set up a ProxyFactoryBean with the ThreadLocalTargetSource as property and the bean name of the supposed-to-be request-scoped object. Something like:


<bean id="threadLocalProxy"
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="targetSource">
<bean class="org.springframework.aop.target.ThreadLocalTargetSo urce">
<property name="targetBeanName" value="objectDoingTheActualWork"/>
</bean>
</property>
</bean>

<bean id="objectDoingTheActualWork" class="your.Object"/>

(Not tested at all!)

You have to inject the proxy into the controller.

Actually I used to rename the proxy to "objectDoingTheActualWork" and the actual object to "objectDoingTheActualWorkTarget".

Jörg

[A Kumar]

Thanks Jörg!!!

I will try to proceed in this way...but one doubt..where are we mentioning that the bean is a request scoped one??

Regards

[A Kumar]

Can we make use of ...lookup-method in bean tag...
below is from spring docs...

http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection


<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="command" class="org.Command" scope="prototype">
<!-- inject dependencies here as required -->
</bean>

<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="org.CommandManager">
<lookup-method name="createCommand" bean="command"/>
</bean>

And the class is...

public abstract class CommandManager {

public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
command.setState(commandState);
return command.execute();
}

protected abstract Command createCommand();
}

[Jörg Heinicke]

Can we make use of ...lookup-method in bean tag...

It's also Spring 2.0, isn't it?

Jörg

[A Kumar]

In spring 1.2.x documentation..

http://static.springframework.org/spring/docs/1.2.x/reference/beans.html#d0e1161


Isnt this approach fine?

[Jörg Heinicke]

In spring 1.2.x documentation..

Isnt this approach fine?

Oh, nice. Yes, that would work as I explained (http://forum.springframework.org/showthread.php?t=41626#2) only yesterday.

Jörg

[A Kumar]

Thanks Jörg!!!!! :)

[A Kumar]

Hi,

Which is the better option...since i have read that with look-up ...
the life cycle of the beans changes.....the spring container creates the bean and injects...similiar to a "new" call...the container forgets about it..and the client code has to handle the sync issues...

In the documentation,

3.4.1
...
Important note: when deploying a bean in the prototype mode, the lifecycle of the bean changes slightly. By definition, Spring cannot manage the complete lifecycle of a non-singleton/prototype bean, since after it is created, it is given to the client and the container does not keep track of it at all any longer. You can think of Spring's role when talking about a non-singleton/prototype bean as a replacement for the 'new' operator. Any lifecycle aspects past that point have to be handled by the client. The lifecycle of a bean in the BeanFactory is further described in Section 3.4.1, “Lifecycle interfaces”.

In such a scenario...which of the options is better....


This is in relation to the app..

http://forum.springframework.org/showthread.php?t=41714

[Jörg Heinicke]

the spring container creates the bean and injects...similiar to a "new" call...the container forgets about it..and the client code has to handle the sync issues...

What sync issues? As the documentation says it behaves like a "new" - which you have now and is supposed to work perfectly since you don't pass this instance around, i.e. to different threads. The lookup-method is a perfect replacement for "new" and getBean("beanName") when making it a prototype bean. You can set up your bean in the XML (which is not possible with "new") and you don't couple your code to Spring (which would happen with getBean()).

Jörg

[A Kumar]

but will those objects...be within the spring .....environment so that spring can provide its own services..?

[Jörg Heinicke]

I don't understand the question. Up to now you had something like

MyObject myObject = new MyObject()

in your code. This gets now changed to

MyObject myObject = getMyObject()

and you add a method

public MyObject getMyObject() {
throw new UnsupportedOperationException("This is supposed to be used with Spring's lookup method functionality.");
}

to it. Now you set up the lookup method and so actually MyObject instance in the XML config. Spring will overwrite the above method throwing the exception with one returning the MyObject instance. Nothing changes from the behavior, but the bean can be set up in the XML config.

Hope that helps,

Jörg

[A Kumar]

Thanks Jorg!!!!!!!!:)