> I believe we don't need a 100% support for the JSR 330 What about portability? Isn't that the point of implementing your services using the JSR330 annotations? If we aren't portable between other implementations then why do it? If you say "supports JSR330" and I bring over a service I wrote using guice's JSR330 implementation I would expect that it would work.
Josh On Tue, Dec 21, 2010 at 4:21 PM, Igor Drobiazko <[email protected]> wrote: > The semantics of both annotation sets are quite similar. So far I've seen > following differences: > 1) javax.inject.Inject may be used to mark static fields as injection points > 2) No injection without @Inject annotation > 3) Injection into void methods (also non setters) > 4) Marker annotations must be annotated with > http://atinject.googlecode.com/svn/trunk/javadoc/javax/inject/Qualifier.html > > I believe we don't need a 100% support for the JSR 330, as we don't need to > pass the TCK. We can just concentrate on providing alternative annotations > for marking injection points. For example the value of injection into static > fields is questionable. > > On Tue, Dec 21, 2010 at 8:30 PM, Howard Lewis Ship <[email protected]> wrote: > >> On Tue, Dec 21, 2010 at 10:33 AM, Igor Drobiazko >> <[email protected]>wrote: >> >> > Yes, we need to make some few changes to tapestry-ioc. >> > >> > I'm not sure I understand what you mean by "we can make changes to >> direclty >> > support JSR-303". Does it mean you prefer to make tapestry-ioc depend on >> > jsr-330 jar? >> > >> >> Yes. >> >> Basically, we have code in tapestry-ioc that says: "find all fields that >> have @org.apache.tapestry5.annotations.Inject" and that needs to change to >> "find all fields that have @tapestry.Inject or @javax.Inject" ... and many >> variations of that in a bunch of places. >> >> There are also some semantic differences; sometimes @Inject means inject a >> service when otherwise a resource dependency would be injected. In other >> places, @Inject means "use this constructor", and in many more places, no >> annotation is needed and Tapestry assumes an injection is desired. Not >> sure >> how well that matches the semantics of the javax @Inject. >> >> >> > >> > On Tue, Dec 21, 2010 at 7:25 PM, Howard Lewis Ship <[email protected]> >> > wrote: >> > >> > > I'm not sure that we can support them without some fundamental changes >> > > inside tapestry-ioc. So we either have to make changes to support an >> > > external library that supports JSR-303 ... or we can make changes to >> > > direclty support JSR-303. I favor the latter. >> > > >> > > I'm hoping that, over several releases. we can go beyond having ids for >> > > services (and instead, rely on marker annotations for disambiguation), >> > and >> > > deprecate @InjectService along the way. >> > > >> > > On Tue, Dec 21, 2010 at 6:41 AM, Igor Drobiazko < >> > [email protected] >> > > >wrote: >> > > >> > > > Ok, keeping own annotations makes sense. Do we want to support >> JSR-303 >> > > > annotations out of the box by adding a new jar depenency to >> > tapestry-ioc >> > > or >> > > > would a new library make more sense? >> > > > >> > > > I tend to the outof the box soluton. >> > > > >> > > > On Tue, Dec 21, 2010 at 12:37 PM, Thiago H. de Paula Figueiredo < >> > > > [email protected]> wrote: >> > > > >> > > > > On Tue, 21 Dec 2010 08:58:40 -0200, Christian Riedel < >> > > > > [email protected]> wrote: >> > > > > >> > > > > Hi Igor, >> > > > >> >> > > > > >> > > > > Hi, guys! >> > > > > >> > > > > >> > > > > I'm not sure about the deprecation but generally it's a good idea, >> I >> > > > >> think. Look at Hibernate and JPA for example. They have kept their >> > > > >> annotations and support the standard ones as well. I like the idea >> > of >> > > > having >> > > > >> the choice... >> > > > >> >> > > > > >> > > > > I was going to post the same opinion. :) I think it wouldn't be >> hard >> > to >> > > > > support both the Tapestry-IoC annotations and the JSR 303 ones. >> We'd >> > > just >> > > > > need to document which one Tapestry would check first and not >> > allowing >> > > > mixed >> > > > > use in the same class. >> > > > > >> > > > > By the way, thanks Igor for stepping up for implementing this. I >> hope >> > I >> > > > > have time to team up with you in this project. >> > > > > >> > > > > -- >> > > > > Thiago H. de Paula Figueiredo >> > > > > Independent Java, Apache Tapestry 5 and Hibernate consultant, >> > > developer, >> > > > > and instructor >> > > > > Owner, Ars Machina Tecnologia da Informação Ltda. >> > > > > http://www.arsmachina.com.br >> > > > > >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: [email protected] >> > > > > For additional commands, e-mail: [email protected] >> > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > Best regards, >> > > > >> > > > Igor Drobiazko >> > > > http://tapestry5.de >> > > > >> > > >> > > >> > > >> > > -- >> > > Howard M. Lewis Ship >> > > >> > > Creator of Apache Tapestry >> > > >> > > The source for Tapestry training, mentoring and support. Contact me to >> > > learn >> > > how I can get you up and productive in Tapestry fast! >> > > >> > > (971) 678-5210 >> > > http://howardlewisship.com >> > > >> > >> > >> > >> > -- >> > Best regards, >> > >> > Igor Drobiazko >> > http://tapestry5.de >> > >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn >> how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> > > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
