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 <[email protected]> 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 <[email protected]>
_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
[email protected]
http://lists.lsc-project.org/listinfo/lsc-dev_
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-dev mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-dev
