Mailing-List: contact any23-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: any23-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ansell.peter@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAqLGLO0ziancvRvoBAgdwFrDXEZv8dX8xDAjR3OzD7y8N8N0w@mail.gmail.com>
References: 
 <CAAqLGLPyFq4jGoC7DvgVJ8D+bMh61ju0-UR+_41MFd19ypydTQ@mail.gmail.com>
	<CAGYFOCTs-DdCzQg3h-JAie=bfTBqz5QAjfStf6tet+neuSkUkA@mail.gmail.com>
	<CAAqLGLO0ziancvRvoBAgdwFrDXEZv8dX8xDAjR3OzD7y8N8N0w@mail.gmail.com>
Date: Sat, 11 Aug 2012 08:08:46 +1000
Message-ID: 
 <CAGYFOCSBBkkJpgOke2N4cEgwwW3ibAyiJJwUwiYyxTQ0Q+9W7g@mail.gmail.com>
Subject: Re: Any23 Modularization
From: Peter Ansell <ansell.peter@gmail.com>
To: any23-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

On 10 August 2012 19:16, Simone Tripodi <simonetripodi@apache.org> wrote:
>> There is at least one statement in that code that I don't think is
>> true in my experience. The author of that JSR says that "Service
>> locators decouple even further but reduce compile time type safety". I
>> am not sure what service locators they have been using, but
>> java.util.ServiceLoader is definitely typesafe, especially if you use
>> it with a Factory interface instead of using reflection to instantiate
>> the object manually. In my experience using java.util.ServiceLoader on
>> my own projects and in my work with OWLAPI, I have found that you can
>> have a typesafe plugin system quite easily without relying on a
>> dependency injection system to do it for you.
>>
>
> they are not indeed the same kind of service locators, and the one you
> are referring is definitely NOT typesafe because in
> META-INF/services/com.acme.Interface definition you are free to
> specify a class which doesn't implement com.acme.Interface - and you
> can find that misconfiguration at *runtime* only.
>
> Modern DI framework allows specify typesafe services in a pure java
> config which is checked at *compile* time.

The purpose of service locators in my experience is to decouple
services so that they are explicitly not required at compile time. It
depends whether you want arbitrary sets of services, or just a single
place to define specific singleton/global services as to whether you
would find it useful to specify services in a compiled java file or in
a configuration file. ServiceLoader is not designed to be a
configuration framework to define specific services, but it is great
if you want to use any and all services that are available.

>From what I can tell, in Any23 we want to load up any and all services
that are available at runtime and the user will specify which one they
want to use with an identifier or MIME-Type, so ServiceLoader fits
that purpose in my view.

> FYI, ServiceLoader is already in use in Any23 to load plugins and
> META-INF/services files are generated at compile time via the metainf
> library developed by Kohsuke (the Jenkin's guy). Anyway, we've had a
> broken test anyway, due to misconfigurations in META-INF/services :)
>
>> However I don't mind if you want to put in JSR-330 annotations in the
>> apprpriate places. I am just wary of cases when a library forces you
>> to use dynamic dependency injection and either makes it very hard or
>> impossible to do it using a plain-old-java way. As long as the code
>> doesn't lock things down by doing things like creating private fields
>> with no accessors or mutators except for DI magic, I am fine with it.
>> Personally, I don't mind maintaining Factories as I am going to be
>> using them myself, since I don't generally use DI, and using Open
>> Source code I am free to create the factories if they don't exist.
>>
>
> I never mentioned adopting a specific framework that forces us on
> writing stuff according to its rule, just referenced to the JRS.
>
> Factories are still fine, but not how they are used in the current
> codebase - they often get me feel lost while reviewing before the
> release.

In the api patch I tried to reduce the confusion, particularly
removing the use of Class.getConstructor in WriterRegistry and
replacing it with a factory. There are two FIXME notes in the patch
where I would like to remove hardcoded factories and format
identifiers.

Cheers,

Peter