[defaultsynchandler] make default sync handler more customisable (Was: [ldap sync] prepopulate a set of users)

[Nicolas Peltier <np...@adobe.com>]

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 <np...@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 <tr...@apache.org> wrote:
>> 
>> Hi Nicolas,
>> 
>> On 14 May 2015 at 07:20:47, Nicolas Peltier (npeltier@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 <tr...@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 <np...@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 <np...@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 
>>>> 
>> 
>> 
>