On Thu, Dec 4, 2008 at 8:10 AM, Ian Boston (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653339#action_12653339 > ] > > Ian Boston commented on SHINDIG-728: > ------------------------------------ > > > Not being Guice expert, I would have thought a > > Object o = injector.getInstance(clazz); > if ( o != null ) { > return o.getClass(); > } > return clazz; > > would be simpler.
It is. The use of getProvider and Key in the patch is unnecessary. > > Also I am not 100% certain that the interface check is safe, its probably > possible to map an concrete class to an abstract class, which is going to > give a class that cant in created. The interface check is wrong; it's perfectly legit to use Guice to bind ConcreteClass.class to SubclassOfConcreteClass.class. > > But anyway, I am no Guice expert and from your use of getProvider() I guess > you are. > >> The Shindig social-api should not use Guice annotations to find its >> implementation classes. >> ------------------------------------------------------------------------------------------- >> >> Key: SHINDIG-728 >> URL: https://issues.apache.org/jira/browse/SHINDIG-728 >> Project: Shindig >> Issue Type: Bug >> Components: RESTful API (Java) >> Reporter: Henning Schmiedehausen >> Attachments: 0001-A-sane-InterfaceClassMapper.patch, >> 0001-Add-testcase-for-InterfaceClassMapper.patch >> >> >> Currently, the social-api uses some clever annotation magic to find its >> implementation classes inside the XStream marshalling/unmarshalling code. >> This code actually does not work with custom object implementations. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
