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