Announcement Announcement Module
No announcement yet.
TypedFactoryGeneratingFactoryBean Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • TypedFactoryGeneratingFactoryBean


    I'm a relatively new Spring user. When researching Spring, I came across this blog post:

    Mike Spille hit a problem that I faced too (creating a Spring-aware factory that, given an id name, returns one of a set of beans of the desired type), and Colin Sampaleanu provided some code that solved it.

    Has this code been made a part of Spring? If not, I've got a version of it that could be added to the main codebase. It adds two additional features not present in Colin's original code:

    1. The ability to specify a default bean to return, in case the id passed in is invalid.

    2. The abiliy to specify a get method that does not have any parameters. This will always return a bean of the specified type (and you will need to only have one bean of the return type registered with Spring). I find that this provides a far better solution to the problem of needing a different instance of a bean on each invocation of a method than the Method Injection method described in Section 3.3.3 of the Spring Docs. This way, I don't need to have abstract methods in all of my Spring Beans if I want to get (for example) a clean reference to my DBHelper objects on each invocation of a method.

    Anyway, if there is any interest, please let me know and I'll contribute the code.


  • #2
    The current CVS codebase, which will be released as Spring 1.1.4 pretty soon, includes a newer version of the code that I posted in the blog entry. The class is now called ServiceLocatorProxyCreator.

    The current code actually allows both getXXXX() and getXXXX(String id), with the former behaving as per your #2, returning based on type, same as if the id is null.

    I've got mixed feelings about making it return a default bean on a non-existent id, although I guess that wouldn't be that big a deal in theory since it would have to be specified explicitly. However, doing that is a bit problematic, since the current implementatin actually supports multiple getXXXX methods....


    • #3
      OK, good to know that your work is going to be included; it's very handy! Will the docs be updated to mention it as another option instead of method injection?

      I added the default bean support, realizing that it would fall apart in the case where you have multiple getXXX methods. But I've found that the common case (in my code, at least) is that there is only one method in the factory, so there's no conflict. I thought about some way to specify a default bean per method, but didn't need it, so I didn't consider the problem much further.