[lsc-dev] Proposal for a change on how to define implementation classes

Maxime Pelletier maxime.pelletier at educsa.org
Thu Jun 27 14:29:54 CEST 2013


  Hi Sébastien,

I already had a look at how to add a plugin. However, as you said, I find
it too complex when all you want to do is to inherit an existing service
class. Plugins sound like a good solution when you want to create a brand
new service, with differents configuration parameters. For example, it
would let me easily use the service
org.lsc.jndi.ActiveDirectoryDstService.java by adding "implementationClass"
parameter to <ldapDestinationService> tag instead of creating all the
necessary configuration for a plugin.

Also, since this discussion is part of my university work, my point is not
really to add a new service, but to improve LSC :)

In short, I'd like to know if you see any problem with my proposal so that
I can create a ticket and start coding.

Regards,
Maxime

Sébastien Bahloul <sebastien.bahloul at gmail.com> a écrit :

> Hi Maxime,       
>    You are right because it's probably too complex, but you can avoid to
> update the lsc-core package code to add a new plugin. Take a look at the
> following page :
>     
>    http://lsc-project.org/wiki/documentation/2.1/development/addingplugin
>     
>    You will find the "standard" extension point to add a plugin. With
> this, you should be able to add a new service just by creating a plugin
> source/destination service.
>     
>    Regards,
>
>
>    Sebastien BAHLOUL
> IAM / Security specialist
> Ldap Synchronization Connector : http://lsc-project.org
> Blog : http://sbahloul.wordpress.com/
>
>    2013/6/26 Maxime Pelletier <maxime.pelletier at educsa.org>
>
>> _Hi all,
>>
>> I decided to examine the code of LSC as part of a course I took at the
>> university. This leads me (and my partner) to the following proposal
>> and I'd like to have your input on it.
>>
>> It is currently quite complicated to extend an existing service (ex:
>> SimpleJndiDstService) in order to specialize it (ex: add special
>> behavior for AD). The main reason I found is that the implementation
>> class of a service is hardcoded in the function
>> org.lsc.configuration.LscConfiguration.getImplementationClass(). In
>> practice, you would have to create a new "plugin" if you want to extend
>> an existing service.
>>
>> My proposal is to move this "mapping" between the configuration file
>> and the mapping class in the XSD. For each service tag in the XSD, we
>> could add a string value named "ImplementationClass" (like for plugin),
>> with a default value equal to the default implementation class. After
>> that, getImplementationClass() function would simply retrieve the
>> implementation class as it is doing right now for plugins.
>>
>> A positive aspect about this proposal is that it is 100% backward
>> compatible since you won't have to specify the implementation class in
>> the XML configuration file unless you want to use a specific class. And
>> since you reuse the same configuration tag, you don't have to modify
>> the XSD file.
>>
>> So let me know what you think about it so that I could better align
>> this proposal with the community needs.
>>
>> Regards,
>> Maxime_
>>
>> ________________________________________________________________
>> Ldap Synchronization Connector (LSC) - http://lsc-project.org
>>
>> lsc-dev mailing list
>> lsc-dev at lists.lsc-project.org
>> http://lists.lsc-project.org/listinfo/lsc-dev_
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lsc-project.org/pipermail/lsc-dev/attachments/20130627/41b65630/attachment.htm>


More information about the lsc-dev mailing list