Dynamic constructor argument

[andy.britz]

Hi all,

I have been using spring for a while and am very happy with the result but I have now bumped into a problem that I am struggling to solve.

I would like to be able to get a bean from the bean factory that is not a singleton and is passed in a dynamic constructor argument. I would like to use the factory so that I can swap out different implementations of the bean. Conceptually I would like to produce the same result as the following fictious method.

MyObject = context.getBean("someId", DynamicRuntimeConstructorArgs);

I have had a good look at the docs and the code but I have thus far failed to find any means of doing this. Any help would be most appreciated.

Thanks
Andy

[jbetancourt]

There have been sevaral inquiries regarding such a capability. Some threads on the old lists on it. Spring doesn't do it, afaik. But, is still being considered?

The closest thing to it is the factory-bean factory-method stuff, in section 3.2.3.3 of reference doc. But, the args are not dynamic.

I wonder if the arguments could be dynamic if they instead come from another dependent bean using the MethodInvokingFactoryBean? See section 3.14. But, that seems overly complex.

Of course, now is the time for someone to chime in and tell me that Spring does allow this, just use this one line declaration.....

--- J. Betancourt

[andy.britz]

Okay well what is the policy on a change request, or submitting changes to the code tree, I am quite happy to add the changes myself if they are deemed to be a useful addition to the tree. I would like to add support for a new bean type of dynamic. After going thought the code and putting some thought into it I would like to suggest the following changes.

Add two methods to the BeanFactory interface:

Object instanciateBean(String name,BeanArguments[] arguments) throws BeansException;

Object instanciateBean(String name, Class requiredType, BeanArguments[] arguments) throws BeansException;

Also add a new interface to the Beans package named BeanArguments that has the following signature.

public interface BeanArguments {

boolean isConstructorArguments();

int getArgumentCount();

Object getArgument(int index);

String getMethodName();

Class getArgumentType(int index);

}

A review of the code indicates that these changes would be quite extensive, and will impact many of the core container classes. Some clarification in the method level contracts such as getBeansOfType(....) will also need to be performed.

Does anyone else feel that this would be a useful exercise?

[jbetancourt]

Andy:

I'm just a Spring user, so what do I know, but you probably should enter an issue in the Spring Jira. http://opensource.atlassian.com/proj...Dashboard.jspa

One point with the name of method, why not just: Object getBean(String name,BeanArguments[] arguments) throws BeansException;


You may also want to check with the sourceforge forums for archives on this topic before beginning any effort. For example, this response: http://sourceforge.net/forum/message.php?msg_id=2693161


-- J. Betancourt

[andy.britz]

Thanks for the pointer, I have had look at the threads, but they do not seem to have any conclusive decision merely a couple of ideas thrown around. I will try to add a request to the jira.

As for the naming of the method, I considered using the standard getBean approach, but since it deviated somewhat from the behaviour of the other getBean methods I thought it might be a good idea to explicitly indicate the behaviour of the method.

On a side note, I do not see any reason why this would encroach on the general spring approach as all the other lifecycle methods should still come into play and you should be able to mix and match statically defined and dynamic arguments.

Admittedly I have only spent a few hours looking at the code but those are my general conclusions.

[jbetancourt]

I agree. I wonder if any IoC system allows this. I looked at Pico and it seems to, but not sure. The page that mentions it has an alert saying its out of date: http://www.picocontainer.org/Configuration

They also have the ConstructorInjectionComponentAdapter class, but not sure if that is intended for 'users'.

Oh well, back to Classpath nightmare with EJBs. :evil:

[andy.britz]

Okay I have created a request on the jira

it is locaed at http://opensource.atlassian.com/proj...browse/SPR-334