[ 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)