New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passing lookup-method arguments to created bean constructor [SPR-7431] #12089
Comments
Cristian Vasile Mocanu commented Spring definitely needs some way to the problem where you want Spring to provide some dependencies and the other dependencies to be provided by the code (because e.g. they are not known until runtime and depend on some computation). Currently, I have to implement factories by hand, and while not complex, it's not fun at all. Guice's way to solve this generic dependency injection issue is AsisstedInject: http://code.google.com/p/google-guice/wiki/AssistedInject The solution to this fix should provide something that solves the same problem as AssistedInject does. |
The Alchemist commented Attaching a patch which adds support for constructs Tomasz talks about. Patch includes:
Thank you, Tomasz, for the blog post which guided me in the process of making this patch.
|
Cristian Vasile Mocanu commented Hi KP, I don't know if your patch already does this, but we should be able to specify some arguments in the Spring configuration and other arguments as parameters to the lookup method in Java. Anything less than this is inferior to Guice's AssistedInject and in this case (where you need to inject some dependencies from the Spring configuration and provide others when calling the lookup method), we still need to create factories by hand. Note that because I'm using DI quite a lot, I'm running very often into this issue. Not all my objects are singletons. The basic problem is the following: now you have a constructor to call. How do you match some constructor parameters to the Spring configuration and the others to the parameters of the lookup method? I get the feeling that fixing this issue, so that we get the something similar to AssistedInject, takes a lot more code than available in the patch. |
The Alchemist commented
My patch allows one to specify constructor arguments, similar in style to |
The Alchemist commented Any luck of this going into 3.1M2? ;) |
Tomasz Nurkiewicz commented Any news on this issue? Plenty of votes and nothing happening here for more than a year. Can we implement the simplest solution and then discuss how can we extend it in future versions? |
Chris Beams commented Hi Tomasz, sorry for the long wait here. The suggestions so far look pretty reasonable -- would you be willing to take the current patch suggestion through the contributor guidelines and get it into a pull request? We can discuss further there, but this already looks like a pretty good candidate for getting into the framework. Thanks! |
Tomasz Nurkiewicz commented Sure, I will do this ASAP. Should the pull request be against master or 3.1.x branch? |
Chris Beams commented master, thanks. |
Chris Beams commented BTW, I just added a section to the contributor guidelines regarding branching from / submitting against master. See "Create your branch from master". |
Tomasz Nurkiewicz commented Submitted pull request: #84 |
Chris Beams commented Waiting for action on review comments on pull request. |
Chris Beams commented Tomasz - just double-checking, have you seen my comments on the pull request? |
Carlos Rodarte commented Has anything happened on this issue? It seems like a pretty handy feature. If Tomasz didn't take action on the code review comments, maybe I can address them :) |
Tomasz Nurkiewicz commented I am terribly sorry for the delay, I promise to address all the issues by the end of next week. |
Chris Beams commented No problem, thanks Tomasz. Note that you'll want to work against 3.2.x at this point, i.e. rebase your current branch against As for timing, please note that we plan to release 3.2.1 on Thursday the 24th. So if you'd like the functionality to make it in by then, you'll want to get it in at least a day before. |
Tomasz Nurkiewicz commented Please have a look at my comment on this pull request. Apparently this change introduces minor (?) backward incompatibility. Not sure how important this is. |
Tomasz Nurkiewicz commented Any updates or thoughts on this issue? Having this feature would stop people from doing hacks like this. |
Juergen Hoeller commented Done for 4.1 now, as a follow-up to #15860... Juergen |
Juergen Hoeller commented A nice bonus: Lookup methods can retrieve a target bean just by their return type declaration as well now, without a bean name specified (i.e. without a 'bean' argument in the lookup-method configuration element). This is based on the actual work in #15860. Juergen |
Tomasz Nurkiewicz opened SPR-7431 and commented
<lookup-method/> should allow specifying any number of parameters. These parameters should be passed directly to the constructor of the newly created bean. For example:
This configuration should be valid and
flight
instance given to createValidator() lookup method should be passed automatically toFlighValidator
constructor.Very rough implementation of this feature (only two lines of code modified!) is discussed here. Similar issue #7703 has been reported and rejected, but its author wanted the lookup-method parameters to be ignored.
Affects: 3.0.3
Attachments:
Issue Links:
@LookupMethod
annotation for use with component scanningReferenced from: commits eb0ab84
44 votes, 38 watchers
The text was updated successfully, but these errors were encountered: