[jira] Updated: (SHINDIG-203) Extract Interfaces from the Social Model to make it easier to Implements Social Containers

["Ian Boston (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SHINDIG-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Boston updated SHINDIG-203:
-------------------------------

    Attachment: SHINDIG-203-non-functioning.patch.gz

Patch updated to SVN r666336

However,

The JSON serialization binds direct to the concrete classes which a) need to be bound to in the social-api impl, and b) need to be mentioned in parameterised constructors to ensure that the serializer is given the correct construction information.

So,
An API on the services with no concrete classes will not work at the moment. The mechanism of creating classes on json-bean needs to bind to factories on non-impl specific classes. Since this area is currently under review, this patch does not work, and is only a snapshot. (there are also some fornatting errors)

> Extract Interfaces from the Social Model to make it easier to Implements Social Containers
> ------------------------------------------------------------------------------------------
>
>                 Key: SHINDIG-203
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-203
>             Project: Shindig
>          Issue Type: Improvement
>          Components: RESTful API (Java)
>            Reporter: Ian Boston
>         Attachments: SHINDIG-203-3.patch, SHINDIG-203-4.patch, SHINDIG-203-non-functioning.patch.gz
>
>
> Currently the PersonService and other API's in the org.apache.shindig.social package contain concrete classes in the form of Pojos to represent the model. Although this is fine, it does limit the implementation strategy to those methods that can operate on PoJos by reflection and building the pojos. For some this is Ok, where there use GCLib or ApsectJ to enhance the Pojos so avoiding excessive Object GC activity, but for those more direct ORM implementations, that already use class extension and a method to make the persistence simpler, concrete classes in the model make it impossible to implement the social model storage.
> The alternative is to copy the object from the  storage into the model, and or add caching outside the storage space. This is quite a lot of code to do property, will replicate a significant amount  of ORM functionality and will have an impact on the GC as more objects will be created and destroyed during each request cycle. 
> Converting the API to interfaces (containing the necessary Enums) will enable any implementation strategy to work (including things like javax.jcr.Node ) and is minimal impact on those that want a Pojo, since they can very quickly implement their own Pojos. It will also prevent the consumer of the API creating object instances and assuming that they will be saved.
> I will attach a patch in a moment, and add a related implementation of the Storage layer that uses interfaces.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.