On 12 November 2012 09:59, Reto Bachmann-Gmür <r...@apache.org> wrote: > Hi Peter and all, > > Good to read about your experiments.Just a first comment: > > In addition, I did not want to use OSGI, so I had to make changes in >> many cases to allow a completely programmatic instantiation of >> components, as some fields were left private with no mutator method >> and in some cases no public contructor that could be used to populate >> the field programmatically. For all of the good that OSGI may provide >> for otherwise complex systems, it is not good Java software >> engineering to make fields private. >> > > The clerezza.rdf package should all be usable withouth OSGi. OSGi cannot do > magic and set private fields, the compiled classes do have bind and unbind > methods for the private fields, these methods are added by the maven felix > scr-plugin. For locating dependencies outside OSGi the META-INF/services > method is used so that for example one can add a serializitaion provider > seimply by adding it to the classpath without requiring and manual binding.
Sorry, I was under the impression that OSGi could actually do Java reflection magic to inject dependencies directly into private fields based on annotations without having any alternative method of setting the field for regular plain old java users. :) In general I would like if OSGi classes that currently rely on bind/unbind, still offered public mutator methods and a public initialise/deinitialise method for any work that needs to be done after using the mutator methods. The bind/unbind methodology from memory when I was working on Clerezza/Stanbol, seemed to require that all of the mutators were run immediately and the initialise was automatically run, without offering any other possible sequence. Additionally, offering public mutators and a public initialise method gives the added benefit of compile-time typesafety for plain old java users, which a bind method taking a Dictionary<String, Object> parameter does not provide. In addition, from memory I think some of the bind methods were protected, and not public, which means they are not directly accessible, without resorting to using reflection or subclassing just to be able to call bind. I use META-INF/services heavily in my projects, and I rely on it when using Sesame and with my extensions to OWLAPI. I extended OWLAPI to use Sesame META-INF/services dependencies to find serialisation/parsing providers for OWLAPI based on the Sesame parser/writer services that are available on the classpath. However, I always try to make sure that the use of the automatically populated service registries is optional, so that users can populate their own registries from scratch using purely programmatic methods, and they do not have to resort to modifying global singleton registries as one does when using Jena. The services that I register in META-INF/services are always factories based on interfaces, so that dependencies can be passed into type-safe java "createServiceInstance" methods when creating instances of the service using the factory instance. This means that it does not matter if the java.util.ServiceLoader loads classes in a different order, as the actual objects are created from the factories explicitly by users, with or without a key to specify which instance of the service they require/prefer. Cheers, Peter
