Sneider - it looks like you have pretty much the correct standard pattern. Here is a more detailed explanation of the "non-Spring beans gaining access to Spring" issues:
Any access to Spring beans must ("should") be done via Spring, i.e. via dependency injection. That is, if you have beans in your code which require Spring dependencies, but are created via a non-Spring creational pattern, the Spring dependencies must be injected into the creator/factory for these non-Spring beans, which it delivers to them via normal routes (e.g. via manually calling constructor arguments or calling setters).
E.g.
Code:
public class NonSpringFactory {
private LeafDependency leafdep;
public void setLeafDependency(LeafDependency leafdep) {
this.leafdep = leafdep;
}
public NonSpringBean createNonSpringBean() {
NonSpringBean nonspring = new NonSpringBean(leafdep);
return nonspring;
}
}
So, NonSpringFactory is configured into your context as a normal Spring bean - LeafDependency is delivered to it via Spring. If for one reason or another (generally most likely as a result of lifetime issues) its product cannot be Spring-configured, and it has LeafDependency as a dependency within Spring, you must use Spring to deliver it to the "closest available point", i.e the nearest Spring-configured bean which in this case is NonSpringFactory. So "LeafDependency" is a "pass-through" dependency which is not a dependency of the Factory, but of its product. At no point should you ever call getBean().
In more complex cases, this idea is the same, only there may be more than one layer of non-Spring creation between source and target, and it becomes increasingly onerous to ferry the dependencies. In Spring therefore the pressure is to de-state-ify your design by working as far as possible with stateless beans which can all be placed in the context, and allowing you to deliver the dependencies precisely to the target.
Until Spring 2.0, the only support for non-singleton beans was as prototypes, which was unsatisfactory since these could not participate in any further injection. Note that now in Spring 2.0 there is support for arbitrary bean scopes, which will help in a lot of cases, although I suspect the 2.0 request scope will be too slow to be suitable for heavyweight work with the request. I will do further tests once we have a full release.
Access application context from code without servlet context
Reply With Quote
come to see the world turn round in such a way that you use Spring/IoC essentially for *everything*, and not worry about questions like "If I have code wanting to use this NonSpringFactory, how does it get a reference to the factory" - yes, the answer is always the same, "by Injection" :P The point is that Spring spreads "everywhere", like a virus - the real benefits of IoC only occur once it is spread across an entire design (the 80/20 rule - 80% adoption only gives 20% of the benefits).