Unfortunately there are some fundamental differences between JSR330 and Tapestry IoC which make it impossible to provide a 100% portability. For example JSR330 dictates that a downcast from an interface to the concrete impl is posible:
MyService service = ... MyServiceImpl impl = (MyServiceIml) service; This won't work with the current implementation of proxies. Tapestry's proxies are generated classes which implement the service interface and delegate to the original implementation. Maybe this issu maybe adressed when migrating fro Javassist to ASM. I believe that using standard annotations for Tapestry services is a big improvement in terms of adoption, even though there will be some limitations with the portability. On Wed, Dec 22, 2010 at 3:11 AM, Josh Canfield <[email protected]>wrote: > > 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] > > -- Best regards, Igor Drobiazko http://tapestry5.de
