Hi Sébastien,
The class org.lsc.jndi.ActiveDirectoryDstService.java is an implementation
plugin with no additional configuration option. This class is part of LSC
but it's quite hard to use it right now.
With my proposal, it would also be easier to extend LSC because it won't be
necessary to add your new service mapping to getImplementationClass().
And the reason why I had a look at this issue (and not the ones in the
tracker) is that it had to be related to design. LSC is using a "strategy"
design pattern to define which service to use. My proposal will reduce
coupling and decrease complexity related to that pattern.
I will create a new request shortly in the tracker, and I should complete
the coding in the next month. At that point, you'll have the chance to
review what I did.
Thanks a lot for your input Sébastien!
Regards
Maxime
Sébastien Bahloul <[email protected]> a écrit :
Hi Maxime,
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:
http://tools.lsc-project.org/projects/lsc/issues :)
Sebastien BAHLOUL
IAM / Security specialist
Ldap Synchronization Connector : http://lsc-project.org
Blog : http://sbahloul.wordpress.com/
2013/6/27 Maxime Pelletier <[email protected]>
_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
