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
