[ 
https://issues.apache.org/jira/browse/SLING-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115225#comment-14115225
 ] 

Stefan Seifert commented on SLING-3886:
---------------------------------------

bq. We should use "Selector" in the interface name unless we're talking about 
Sling selectors. How about "Picker" instead.
yes, of course, thought about that variant as well. will update the patch.

bq. Can the synchronized block in AdapterImplementations.lookup() be removed?
i tried to keep the synchronization as small and local as possible - in this 
case the synchronization will only affect multiple threads which access exactly 
the same adapter class. but - if this is much used - this can still block a lot 
of threads you are right.
hmm, the "implementations" is a treemap because we need the ordering to have a 
consistent selection behavior, otherwise we could use a ConcurrentHashMap as 
well.
i'm not the best expert at concurrency programming. perhaps 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentSkipListMap.html
 is an alternative. will have a look into it.

> Sling Models: support adapters for models different from the implementation 
> class
> ---------------------------------------------------------------------------------
>
>                 Key: SLING-3886
>                 URL: https://issues.apache.org/jira/browse/SLING-3886
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Stefan Seifert
>              Labels: models
>             Fix For: Sling Models Implementation 1.1.0, Sling Models API 1.1.0
>
>         Attachments: 140827_SLING-3886_adapters_support.patch, 
> 140829_SLING-3886_adapters_support.patch
>
>
> currently, as adapter (adaption target) only the implementation class itself 
> that is annotated with the @Model annotation is supported (which can be 
> either an interface or a class).
> if the model is not just a simple model but a class with more complex 
> business logic the following scenario is required:
> * a "service" interface is defined
> * this service interface ist not directly mapped to injected values, but 
> provides higher-level method
> * an implementation class with @Model annotation is implemented which gets 
> the required values injectd internally, but implements the interface for 
> outside access
> this is currently not possible with sling models.
> the attached patch extends the following features:
> * extends the @Model annotation with an optional "adapters" attribute
> * if defined, only the listed adapters are registered for the adapter 
> factory, not the implementation class itself (unless it is listed the 
> "adapters" attribute as well)
> * in the adapters attribute only the implementation class itself or 
> interfaces that it implements or superclasses can be defined
> * with this the scenario above is perfectly possible
> * unit tests included which simulate the bundle add/remove usecases which is 
> required to do the indirect implementation class mapping



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to