Hi Tobias,
as discussed off list, this defaultsynchandler customisation discussion we had
joins the one started here [0]. So i’ll dump my findings, and we can see in
which directions to go (or in which direction patches are the more welcome ;-)
First, as is, it’s not about making only this class public, but all its
dependencies :DebugTimer, DefaultSyncConfig, SyncedIdentityImpl and
SyncResultImpl.
Then i’m not sure that’s worth it as the core of the code that is interesting
for users to extend is DefaultSyncHandler.ContextImpl that does a lot of atomic
and very interesting operations (i won’t list all the methods, but they are
almost all here). This to say that even if we were able to extend it, we would
end up doing things like:
blah() {
//my stuff before
super.blah();
//my stuff after
}
and i wonder if making contextimpl heavily pluggable with osgi bindings (called
after and before each sync, and may be also after the initial configuration)
wouldn’t do the trick, wdyt? e.g. [0] could be fixed by adding a component
checking the user attribute
Nicolas
[0] https://issues.apache.org/jira/browse/OAK-2948
> On 15 May 2015, at 16:16, Nicolas Peltier <npelt...@adobe.com> wrote:
>
> Ok let’s do this, i might do the same with LdapIdentityProvider (paged
> search, see other thread), once i got those working, we’ll create appropriate
> JIRAs.
> Thanks,
>
> Nicolas
>> On 14 May 2015, at 20:31, Tobias Bocanegra <tri...@apache.org> wrote:
>>
>> Hi Nicolas,
>>
>> On 14 May 2015 at 07:20:47, Nicolas Peltier (npelt...@adobe.com) wrote:
>>
>> Hi Tobias,
>>
>> thanks a lot for those infos. I just realised i need to implement some
>> custom behaviour to the synchandler, however there is already quite a (big)
>> piece in DefaultSyncHandler. Unfortunately, DefaultSyncHandler is located
>> under private impl package and will not be available to my application.
>> Could DefaultSyncHandler be moved to the public part?
>> As you realise, the DefaultSyncHandler is not build to be extended (yet). we
>> could move it outside the impl package, but we probably also need to make it
>> deliberately extensible. We should probably split it in 2 parts, a class
>> that does the syncing, and the class for the service. extending the service
>> directly is usually tricky.
>>
>> I suggest, you copy the DefaultSyncHandler.java to your bundle and try to
>> extend it and/or break it apart. If you then can tell me what customisation
>> you needed, we can properly create public classes.
>>
>>
>>
>> WDYT?
>>
>> Regards, Toby
>>
>>
>>
>>
>>
>> Nicolas
>>> On 06 May 2015, at 19:05, Tobias Bocanegra <tri...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> have a look at the SyncMBeanImpl [1] that does something similar. you
>>> might be even able to use the MBean from your code.
>>>
>>> Regards, Toby
>>>
>>> [1]
>>> https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.2.2/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/jmx/SyncMBeanImpl.java#L179
>>>
>>>
>>> On Wed, May 6, 2015 at 2:13 AM, Nicolas Peltier <npelt...@adobe.com> wrote:
>>>> To be clearer, said in a different way, i’d like to pull a given set of
>>>> users (LDAP query) from a LDAP server in a scheduled manner, using at most
>>>> the oak code :-)
>>>>
>>>> Nicolas
>>>>> On 06 May 2015, at 11:09, Nicolas Peltier <npelt...@adobe.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> i’m implementing an application where users can look at each other’s
>>>>> profile, which data comes mainly from a LDAP server. I was wondering how
>>>>> feasible it was to tweak user sync to achieve this, as i am under the
>>>>> impression reading the documentation [0] that sync is only designed to be
>>>>> done at a given user’s login time.
>>>>>
>>>>> Can someone shed some light on this?
>>>>> Thanks!
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>> [0]
>>>>> https://jackrabbit.apache.org/oak/docs/security/authentication/usersync.html
>>>>>
>>>>
>>
>>
>
