[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010913#comment-15010913
]
Nicolas Peltier commented on OAK-2948:
--------------------------------------
[~tripod] (cc [~kwin]), there is still something wrong i'd say, or i don't see
a solution for which the defaultsyncconfig handling:
DefaultSyncConfig parameters are all set in implementation of it, and only way
to get DefaultSyncConfig is through the implementation that is not exported,
with the .of(..) method.
Creating my own SyncHandler thus needs to copy the full DefaultSyncConfigImpl
configuration...
i guess what we could have here is a public activate method (so i can call
super.activate(..))?
> Expose DefaultSyncHandler
> -------------------------
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
> Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
