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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
