[
http://www.stripesframework.org/jira/browse/STS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11296#action_11296
]
Christian Nelson commented on STS-520:
--------------------------------------
Gregg, I'm getting the feeling we're not really talking about the same thing.
In my proposition, no core part of Stripes would be tied to Spring. I'm only
talking about providing Spring integration for dependency injection using
Spring's native annotations. Only people who wanted Spring support would use
these annotations and would be required to depend on Spring (they would
*already* have a dependency on Spring). If someone didn't want dependency
injection, there would be no dependency on Spring.
The attached file (SpringInterceptor.java) is a complete Stripes
SpringInterceptor implementation which allows for the use of Spring 2.5's
@Autowired, @Qualifier, and the Java @Resource on Stripes action beans. It's
wired up exactly like the SpringInterceptor which ships with Stripes. As far
as I can tell, it is quite a bit smaller (lines of code) than the existing
Spring integration and it provides the same exact syntax and semantics that
Spring provides. If a user wants Spring support, it's hard to argue that they
would want syntax and semantics of something other than Spring.
Note that in this code sample, no part of Stripes would have to change if
Spring changes its annotations. And for the record, Spring has retained an
almost perfect record of backwards compatibility since v1.0 many years ago. So
I don't buy the "isolating stripes from changes in spring over time" argument.
I'm confident that I could create an equally simple GuiceInterceptor for those
users who want Guice integration. And then, those who want Guice integration
would be able to use the syntax and semantics of what they are used to.
"What if Stripes decides it needs/wants more options available during the
injection?" Like what? What would Stripes want to add to its Spring
Integration support that Spring itself does not provide? Better yet, how would
Stripes be able to provide more dependency injection functionality than the
underlying dependency injection container? If a user wanted something that
Spring couldn't provide itself in terms of dependency injection, then the user
would look for a different DI framework, not expect their lightweight MVC to
augment.
Anyones else following this have an opinion?
> Support Spring's @Autowired annotation for marking fields/methods for
> dependency injection
> ------------------------------------------------------------------------------------------
>
> Key: STS-520
> URL: http://www.stripesframework.org/jira/browse/STS-520
> Project: Stripes
> Issue Type: Improvement
> Affects Versions: Release 1.4.3
> Reporter: Christian Nelson
> Priority: Trivial
>
> It'd be nice if we could use the @Autowired annotation that was recently
> added in Spring 2.5 in place of the @SpringBean annotation. Dependency
> injection would then would be consistent with a spring-managed service tier.
> Obviously this isn't a big deal and I've marked it as trivial.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
