This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Dynamic constructor argument

Sep 15th, 2004, 05:46 AM

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.

Comment

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.

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.

Comment

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.