Need a dependency injection framework

[Martin Desruisseaux <ma...@geomatys.fr>]

Hello all

I committed today a "DefaultNameFactoryTest" file. If one looks at the 
source code [1], the interesting aspect is that this file doesn't 
contain any test. Instead it just creates a SIS DefaultNameFactoryTest 
instance, passes it to the super-class constructor and inherits all the 
tests defined in GeoAPI [2]. This illustrates the GeoAPI 
inter-operability goal, admittedly only at the test suite level in this 
case.

In this test case, DefaultNameFactory is instantiated directly. However 
in a production environment, we need to allow users to specify their own 
Factory instance. In Geotk, we tried to do that using 
java.util.ServiceLoader. However while ServiceLoader is still very well 
suited to situations where we need *all* instances of a given interface 
(all map projections, or image readers for all formats, etc.), it become 
difficult when we need to select one instance among many possibilities. 
An alternative proposed years ago was to use Spring, but I would like to 
avoid making such dependency mandatory.

Since 2009, JSR-330 [3] is providing an @Inject annotation for that. 
JSR-330 is a 2.4 JAR file available on Maven central under Apache 2 
license, so it seems a reasonable dependency. Note that JSR-330 provides 
only annotations - implementations is another matter, discussed below.

Those annotations are now included in JEE 6 [4]. So they do not 
introduce any new dependency in JEE environments. But it would introduce 
dependency in JSE environments. In addition to the above-cited JSR-330 
JAR files, JSE environments would need an implementation. One impossible 
implementation is Google Guice [5], also available on Maven Central 
under Apache 2 license. However this is an almost 700 kb dependency, 
with some transitive dependencies (I didn't analysed them yet). However 
I'm not yet familiar with Juice - in particular does it forces 
applications to be run is some kind of containers?

An alternative could also be to provide our own trivial implementation 
(just hard-coded references to the factory implementations), which users 
can replace by Guice or JEE when such environment in available. Since I 
have never experimented JSR-330 yet, I don't know if it is a reasonable 
approach.

Any though?

     Martin


[1] 
https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/test/java/org/apache/sis/util/type/DefaultNameFactoryTest.java
[2] 
http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/util/NameTest.html
[3] http://jcp.org/aboutJava/communityprocess/final/jsr330/index.html
[4] http://docs.oracle.com/javaee/6/api/javax/inject/package-summary.html
[5] http://code.google.com/p/google-guice/

Re: Need a dependency injection framework

[Martin Desruisseaux <ma...@geomatys.fr>]

Le 10/12/12 18:21, Martin Desruisseaux a écrit :
> One impossible implementation is Google Guice
Typo: I mean "one possible implementation"

     Martin

Re: Need a dependency injection framework

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Hey Martin,

My +1 here would be for Guice or for Spring -- (though Spring introduces a
ton of bloat).
I've heard good things about Guice and 700kb is pretty small compared to
Spring :)

Cheers,
Chris

On 12/10/12 1:21 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:

>Hello all
>
>I committed today a "DefaultNameFactoryTest" file. If one looks at the
>source code [1], the interesting aspect is that this file doesn't
>contain any test. Instead it just creates a SIS DefaultNameFactoryTest
>instance, passes it to the super-class constructor and inherits all the
>tests defined in GeoAPI [2]. This illustrates the GeoAPI
>inter-operability goal, admittedly only at the test suite level in this
>case.
>
>In this test case, DefaultNameFactory is instantiated directly. However
>in a production environment, we need to allow users to specify their own
>Factory instance. In Geotk, we tried to do that using
>java.util.ServiceLoader. However while ServiceLoader is still very well
>suited to situations where we need *all* instances of a given interface
>(all map projections, or image readers for all formats, etc.), it become
>difficult when we need to select one instance among many possibilities.
>An alternative proposed years ago was to use Spring, but I would like to
>avoid making such dependency mandatory.
>
>Since 2009, JSR-330 [3] is providing an @Inject annotation for that.
>JSR-330 is a 2.4 JAR file available on Maven central under Apache 2
>license, so it seems a reasonable dependency. Note that JSR-330 provides
>only annotations - implementations is another matter, discussed below.
>
>Those annotations are now included in JEE 6 [4]. So they do not
>introduce any new dependency in JEE environments. But it would introduce
>dependency in JSE environments. In addition to the above-cited JSR-330
>JAR files, JSE environments would need an implementation. One impossible
>implementation is Google Guice [5], also available on Maven Central
>under Apache 2 license. However this is an almost 700 kb dependency,
>with some transitive dependencies (I didn't analysed them yet). However
>I'm not yet familiar with Juice - in particular does it forces
>applications to be run is some kind of containers?
>
>An alternative could also be to provide our own trivial implementation
>(just hard-coded references to the factory implementations), which users
>can replace by Guice or JEE when such environment in available. Since I
>have never experimented JSR-330 yet, I don't know if it is a reasonable
>approach.
>
>Any though?
>
>     Martin
>
>
>[1] 
>https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/test/ja
>va/org/apache/sis/util/type/DefaultNameFactoryTest.java
>[2] 
>http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/util/Nam
>eTest.html
>[3] http://jcp.org/aboutJava/communityprocess/final/jsr330/index.html
>[4] http://docs.oracle.com/javaee/6/api/javax/inject/package-summary.html
>[5] http://code.google.com/p/google-guice/
>