[
https://issues.apache.org/jira/browse/SHINDIG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated SHINDIG-728:
-------------------------------------------
Attachment: 0001-A-sane-InterfaceClassMapper.patch
This is a better implementation of the InterfaceClassMapper which uses Guice to
ask what is the current implementation of an interface.
Due to a Guice limitation (you can only get an instance from a Provider, not
the class it provides), this actually instantiates an object every time it
needs to find out the class mapping. As XStream caches this internally, this
shouldn't be a problem; however if the class generation has some internal side
effects (which it should not have as long as these are simple beans), this
means that one bean more is instantiated than expected. Caveat Emptor.
> 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.
