|
Sort Order:
Regarding point 1, I was actually considering using this to inject statics. Will this be switchable within 2.1 M4 or is there any other method of achieving this? The scanner now accepts a 'resourcePattern' that is appended to each base package when scanning. The default value is "*/.class". This pattern can be provided via xml with the new 'resource-pattern' attribute of the 'component-scan' element. Brilliant! Wouild really appreciate a comment on this, as I was just about to use the component scan Static injection (side-affect) within a live project. IMO, injection is about setting bean instance behavior, not class behavior. However, I'd like to hear an opposing point of view. Not sure whether my view is opposing. Really it's just been driven by the requirements of the Domain, and an attempt to keep the code simple. AggregateRootDO.findby(someID); In this way we don't need to instantiate an object, prior to finding one. Within the AggregateRootDO, the static findby method references the static instance of the Repository interface. Currently we have to retrive this from the Context Application as we can not inject the static, which has the detremental effect of making the Domain Objects dependant upon some framework code. The static injection through Spring using the component scanning and @Component, was attractive so that we could remove this dependency. Marc Technically, what you're doing there is creating an instance of your AggregateRootDO class (it is autodetected through the @Component annotation and turned into a singleton bean instance), injecting that singleton instance and then offering static accessors on that AggregateRootDO class. Exposing static configuration state in that way isn't incredibly clean architecturally; that said, I agree that it may be quite convenient in some scenarios. For that arrangement to work, simply let your AggregateRootDO class have non-static setter methods with an @Resource or @Autowired annotation. Those setter methods can then in turn store their passed-in object in a static field, with the static accessor methods obtaining the reference from that field. So the configuration actually still happens on an instance (with the annotations sitting on instance methods), just with the class offering a static accessor. The conceptual problem here is that annotation-driven injection happens for each bean instance. So we shouldn't inject static fields or static methods there because that would happen for every instance of that class. The injection lifecycle is tied to the instance lifecycle, not to the class lifecycle. Bridging between an instance's state and static accessor - if really desired - is up to the concrete bean implementation but arguably shouldn't be done by the framework itself. Juergen Thanks so much for the infmormative reply, which has served to fully explain the underlying conceptual and archictectural issues. Mark, could you update the new xsd at http://www.springframework.org/schema/context/spring-context-2.1.xsd Thanks! Leonardo, I have updated all of the 2.1 schemas at springframework.org to the 2.1-M4 release versions. Note that 2.5 versions are now available as well. If you are using nightly builds, you can point to 2.5 instead (since 2.5 has superseded 2.1). Mark Thank you very much! Leonardo |
|||||||||||||||||||||||||||||||||||||||||||||
Improvement
Resolved
Minor
Improving component-scan performance through more specific search patterns
Thanks for pointing this out! The problem with static injection was simply that we didn't check for static fields and methods there... neither for @Resource nor for @Autowired or @PersistenceContext. I have added explicit checks there now, throwing an exception if such an annotation is found on a static field/method. This will already be available in the next 2.1 M4 snapshot.
Turning this issue into an enhancement request for improving component-scan's performance now, assigning it to Mark.
Juergen