incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject Re: Future of Clerezza and Stanbol
Date Mon, 12 Nov 2012 14:03:18 GMT
Hi Peter,

I think it would be good to improve the rdf libraries for non OSGi usage,
your suggestion sound very reasonable. The design was strongly driven by
the requirements in OSGi environments. Your interest in these libraries
reinforces my believe that they should be maintained as an independent
project.

There are also some naming issues to discuss.

URIRef -> IRI
TcProvider -> Dataset
TcManager -> DefaultDataset

I suggest to discuss improvement of the API outside this future of
clerezza/stanbol thread.

Cheers,
Reto

On Mon, Nov 12, 2012 at 2:15 AM, Peter Ansell <ansell.peter@gmail.com>wrote:

> On 12 November 2012 09:59, Reto Bachmann-Gmür <reto@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message