[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013187#comment-15013187 ] Nicolas Peltier commented on OAK-2948: -- [~tripod], so there might something i don't understand: to implement my custom solution, i need to implement my own SyncHandler, right? and if i'm happy with the current config, i'd like to reuse implementation of DefaultSyncConfig in the same way DefaultSyncHandler does [0]. Ideally i could extend DefaultSyncHandler but this one is not exposed neither. [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L87 > 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014123#comment-15014123 ] Tobias Bocanegra commented on OAK-2948: --- yeah, the {{DefaultSyncConfigImpl}} separates the configuration for the {{DefaultSyncHandler}}: {noformat} @Component( label = "Apache Jackrabbit Oak Default Sync Handler", name = "org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler", configurationFactory = true, metatype = true, ds = false ) {noformat} so basically it's the same as if it would be in the same class as DefaultSyncHandler. we just separated it so that we can have a own pojo for the config for non osgi use cases. If you create your own sync handler, you obviously need your own component configuration. currently, you need to copy-paste it. correct. > 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013534#comment-15013534 ] Konrad Windszus commented on OAK-2948: -- @Nicolas Peltier: It is right that currently you have to reimplement your own {{DefaultSyncConfigImpl.of(ConfigurationParameters params)}}. > 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011568#comment-15011568 ] Tobias Bocanegra commented on OAK-2948: --- no, the class is public: {{org.apache.jackrabbit.oak.spi.security.authentication.external.basic.DefaultSyncConfig}} > 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648851#comment-14648851 ] Nicolas Peltier commented on OAK-2948: -- Thanks for the tip [~kwin]! will try that 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 groupIdorg.apache.felix/groupId artifactIdmaven-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-Packageorg.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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647686#comment-14647686 ] Nicolas Peltier commented on OAK-2948: -- Hi [~tripod], how complicated would that be to backport this fix in 1.2 branch? I'd need this in an AEM 6.1 project, and using 1.3.2 seems just impossible 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14629506#comment-14629506 ] Konrad Windszus commented on OAK-2948: -- The fix version is wrong. This change is only part of 1.3.2. 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.0 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571387#comment-14571387 ] Tobias Bocanegra commented on OAK-2948: --- bq. In our case we face an issue, that the membership is being listed in a user attribute, rather than in a group attribute. so would it make sense to make this a configurable option in the default sync handler? ..and as always: patches welcome :-) 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 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)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[ https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14569390#comment-14569390 ] Tobias Bocanegra commented on OAK-2948: --- this request came up recently elsewhere. I think it makes sense - although extending an osgi service is usually not such a good idea. but we could split the handler in a service and a handler part, and expose the later. 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 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)