0

I'm sure this has been asked a hundred times before but I can't seem to find the question so feel free to refer me to other stackoverflow answers.

What do most Spring users do for objects that are non-singleton beans that require injection? For example, I have classes like Customer where I want to instantiate a new one each time. Lets say it is an entity and I want to inject listeners to iterate through in @PreRemove or somewhere else. The usual solution is to use @Configurable but that almost seems a workaround and I was wonder if there was a more canonical way to handle these.

The only thing I can think of is to create a factory newCustomer instance method in my CustomerRepository class which IS a managed bean. Then instead of injecting listeners into Customer (the most natural place) I inject them into the CustomerRepository and specify them as an explicit constructor argument to Customer ala new Customer( injectedListeners ).

Do people tend to just use Configurable or is there a better way to inject non-singleton instances? Or do most users create a factory method as above? The entity example is just an example, I have other objects that are non-singleton, are typically new'd but require injection.

Would this be handled differently in something like Guice? How would you do it just using JSR-330 features?

robert_difalco
  • 4,821
  • 4
  • 36
  • 58

1 Answers1

0

You can make beans non-singletons if you like. Depends on whether you are ok with the XML:

<bean id="beanA" class="misc.BeanClass" scope="prototype">
    <property ... />
</bean>

Which will give you a new instance every time. Each instance will be initialized with injected values.

You can use this annotation too:

@Scope("prototype")
Lee Meador
  • 12,829
  • 2
  • 36
  • 42
  • Is that how you would handle a Customer class that required injection? Make it a bean? Seems overkill. I think I'm missing a pattern that would be better rather than making every non-service object that can be injected a bean. – robert_difalco Aug 02 '13 at 20:56
  • And if it is a bean I still have the issue of explaining the design of having to use #getBean or some such instead of "new Customer()". – robert_difalco Aug 02 '13 at 20:57
  • 1
    You can have a static `getInstance()` method to do that for you. OR. If you use "new Customer()" you can put code in the constructor to manually inject whatever by calling `getBean()` and storing, too. If there are a lot of them, put that injector code in a parent constructor and make it generic. – Lee Meador Aug 02 '13 at 21:01
  • I think most natural for the user would be to make CustomerEntity Context Aware and just get the beans manually rather than trying to get it to use @Inject. I think it would be too weird to create a contract for users of the class to call a factory method to create new instances. I have no way to enforce that usage. – robert_difalco Aug 02 '13 at 21:13
  • Or make it @Configurable :) – Lee Meador Aug 02 '13 at 21:32
  • Yup. Which is basically how I do it now. :) Was really hoping I could find a way that would work with just JSR-330 annotations. But oh well. Thanks for your help. – robert_difalco Aug 02 '13 at 22:08