[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14648820#comment-14648820
]
Konrad Windszus commented on OAK-2948:
--------------------------------------
[~npeltier] You can just embed the new classes in your own bundle (with your
custom sync handler). I use that in an AEM 6.1 bundle for a custom sync handler:
{code}
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<!-- embed via static linking the new Oak 1.3 classes
(http://njbartlett.name/2014/05/26/static-linking.html)
oak commons in version 1.3 is dependent
-->
<instructions>
<Conditional-Package>org.apache.jackrabbit.oak.spi.security.authentication.external.basic,org.apache.jackrabbit.oak.commons</Conditional-Package>
</instructions>
</configuration>
</plugin>
{code}
> 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
>
>
> 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)
