That's great. Looking forward to use it. On Wed, Dec 22, 2010 at 7:59 PM, Josh Canfield <[email protected]>wrote:
> It should. I don't think the semantics are different from the tests > that I've written. You will need to bind the Provider as a service > with the generic type. I'm going to start checking it in piece-wise > over the next week-ish. I don't have the code in front of me now but > I'll make sure this case works. > > Josh > > On Wed, Dec 22, 2010 at 8:34 AM, Igor Drobiazko > <[email protected]> wrote: > > @Josh: will you generic patch allow something like that? > > > > public Foo(Provider<Bar> provider) { ... } > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best regards, Igor Drobiazko http://tapestry5.de
