See inline Am 08.07.11 19:53, schrieb Wes Wannemacher: > On Fri, Jul 8, 2011 at 1:35 PM, Paul Benedict <pbened...@apache.org> wrote: >> I would leave it alone. Hibernate has many custom annotations with the >> same name as JPA annotations... if you need both, one needs to be >> fully qualified. >> > > I agree with Paul, one of the benefits of having packages is the > ability to have classes with the same name. There is no reason to > change the name of the annotation. >
+1 >> As developers prefer CDI over XWork annotations, then Struts' @Inject >> will fall out of use. >> > > A while back, I remember Don Brown mentioning that it is a good idea > to keep the IoC/DI of the framework separate from the IoC/DI available > for users. I agree with this sentiment. Because of that, i don't think > we'll see our own @Inject fall out of use, internally. And, I don't > think our users are using @Inject in their web-apps. If we want to > properly support CDI for users, I think we should build an > ObjectFactory that is aware of CDI and allow users to register their > own container with it. If I remember correctly, someone started that > in the sandbox? > +1 as well. If an "end-user" wants to make use of XWork's @Inject he would most probably a) know what and why he is doing b) not use JSR-330 @Inject in the same class Just to be clear, @Inject is not part of CDI but of JSR-330 (javax.inject), on which CDI (JSR-299) builds. The JSR-330 API is a minimalistic jar with AFAIR 3 or 4 annotations definied, which makes it easy to bind again without worries. That said, it might be an interesting thought to extend the core object factory to respect standard @Inject as an alternative to XW's @Inject, unless the CDI plugin "overrules" with delegating to a fully featured CDI container. Anyway, I don't see the benefit of such an drastic API change as renaming one of our core annotations. - René > -Wes > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
