[lsc-dev] Proposal for a change on how to define implementation classes
sebastien.bahloul at gmail.com
Thu Jun 27 15:09:44 CEST 2013
In short, if this is just an implementation plugin, that's OK. But if this
plugin requires any additional configuration options, you should consider
either to extend the LSC (and you are welcome to create a extended AD
service) or create a project including XSD extension.
By the way, there's probably a lot of other ways to improve LSC:
IAM / Security specialist
Ldap Synchronization Connector : http://lsc-project.org
Blog : http://sbahloul.wordpress.com/
2013/6/27 Maxime Pelletier <maxime.pelletier at educsa.org>
> 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.
> 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 :
> 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.
> 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.
>> Ldap Synchronization Connector (LSC) - http://lsc-project.org
>> lsc-dev mailing list
>> lsc-dev at lists.lsc-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lsc-dev