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]

Reply via email to