You have to differentiate between XWork's internal injection and the injection abstraction towards user code to support pluggable dependency injection implementations. The latter one we surely would not want to drop, and as a matter of fact we are already supporting JSR 330 with the Spring, Guice and CDI plugins.
As for internal injection, the question is not so much whether we would want to switch to JSR 330 but rather to what actual injector implementation. That is, stay with the baked in pre-release Guice code or switch to an externally maintained framework such as Guice 3. If we'd go for that, we'd automatically introduce JSR 330 into our internal injection mechanism. If we go for replacing the internal injector, there isn't actually too much choice - Guice or Guice seem to be the options - or, if we feel adventurous enough, maybe Dagger :) Spring as most widely used alternative is too heavy-weight. Also, since our internal framework *is* actually early Guice, some core concepts of how things are implemented now would have a natural mapping. I've looked into this task for quite some time now and I can confirm that this is not trivial. The internal injector is not easy to fiddle out and replace, but I'm all for giving it a try once we have started creating the 3.0 code base. As for the Struts 2.x line, the risk was way too high to touch the injection mechanism while keeping the framework stable. Only now there is a chance to get hands dirty on this one :) Am 28.11.12 07:43, schrieb Paul Benedict: > What about dropping XWork injection support for JSR 330 (Commons DI)? > > On Wed, Nov 28, 2012 at 12:41 AM, Lukasz Lenart > <lukaszlen...@apache.org>wrote: > >> I've updated the plan :-) >> >> Request Git repo from INFRA >> Import project >> Remove deprecated plugins >> Drop support for Struts 1 (remove plugin) >> Remove deprecated APIs >> Switch to Java 1.6 >> Rename XWork packages to org.apache.struts.xwork >> Rename Struts 2 packages to org.apache.struts >> Prepare the first release >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > -- René Gielen http://twitter.com/rgielen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
