You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Ben Tomasini <be...@gmail.com> on 2007/09/28 19:32:12 UTC
T5: Automatic dependency resolution and generics
I have a service which implements an interface with a generic type. The
builders look like this:
ReadWriteState<User> buildUserState()
ReadWriteState<Item> buildItemState()
I have the following dependency injection:
MyService buildMyService(ReadWriteState<User> userState)
The automatic dependency injection sees two matches, since it is not
qualifying the type with the generic. Is there any good reason that these
two services cannot be seen as unique based on their generic type?
Ben
Re: T5: Automatic dependency resolution and generics
Posted by Ben Tomasini <be...@gmail.com>.
Thanks.
For now I am just using @InjectService("UserState") and it does the job. I
was just hoping the typing could save me from typing. :)
Ben
On 9/28/07, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> It's about the type erasure; for the most part the <User> and <Item> get's
> stripped off method signatures as they get compiled.
>
> This is a tough nut to crack. Some of the type data needed for this match
> may be available at runtime.
>
> You may need to
>
> public interface ReadWriteUserState extends ReadWriteState<User>
> {
> }
>
> to make this work in the meantime.
>
> On 9/28/07, Ben Tomasini <be...@gmail.com> wrote:
> >
> > I have a service which implements an interface with a generic type. The
> > builders look like this:
> >
> > ReadWriteState<User> buildUserState()
> >
> > ReadWriteState<Item> buildItemState()
> >
> > I have the following dependency injection:
> >
> > MyService buildMyService(ReadWriteState<User> userState)
> >
> > The automatic dependency injection sees two matches, since it is not
> > qualifying the type with the generic. Is there any good reason that
> these
> > two services cannot be seen as unique based on their generic type?
> >
> > Ben
> >
>
>
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
>
Re: T5: Automatic dependency resolution and generics
Posted by Jesse Kuhnert <jk...@gmail.com>.
it's a huge pita....but maybe this would help for something done in the future:
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/enhance/GenericsMethodSignatureImpl.java?view=markup
On 9/28/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> It's about the type erasure; for the most part the <User> and <Item> get's
> stripped off method signatures as they get compiled.
>
> This is a tough nut to crack. Some of the type data needed for this match
> may be available at runtime.
>
> You may need to
>
> public interface ReadWriteUserState extends ReadWriteState<User>
> {
> }
>
> to make this work in the meantime.
>
> On 9/28/07, Ben Tomasini <be...@gmail.com> wrote:
> >
> > I have a service which implements an interface with a generic type. The
> > builders look like this:
> >
> > ReadWriteState<User> buildUserState()
> >
> > ReadWriteState<Item> buildItemState()
> >
> > I have the following dependency injection:
> >
> > MyService buildMyService(ReadWriteState<User> userState)
> >
> > The automatic dependency injection sees two matches, since it is not
> > qualifying the type with the generic. Is there any good reason that these
> > two services cannot be seen as unique based on their generic type?
> >
> > Ben
> >
>
>
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Automatic dependency resolution and generics
Posted by Howard Lewis Ship <hl...@gmail.com>.
It's about the type erasure; for the most part the <User> and <Item> get's
stripped off method signatures as they get compiled.
This is a tough nut to crack. Some of the type data needed for this match
may be available at runtime.
You may need to
public interface ReadWriteUserState extends ReadWriteState<User>
{
}
to make this work in the meantime.
On 9/28/07, Ben Tomasini <be...@gmail.com> wrote:
>
> I have a service which implements an interface with a generic type. The
> builders look like this:
>
> ReadWriteState<User> buildUserState()
>
> ReadWriteState<Item> buildItemState()
>
> I have the following dependency injection:
>
> MyService buildMyService(ReadWriteState<User> userState)
>
> The automatic dependency injection sees two matches, since it is not
> qualifying the type with the generic. Is there any good reason that these
> two services cannot be seen as unique based on their generic type?
>
> Ben
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind