Just finished all the main features I'd like to see in the DI
container. So here is a new checklist:
* annotation-based field dependency injection
* annotation-based constructor dependency injection
* injection of map and list "configurations" (allows to add things
like extra ExtendedTypes)
* binding interfaces to implementation classes via fluent API
* binding interfaces to "provider" (same as "factory") classes
* merging multiple DI "modules"
* dependency cycle detection
The container is still pretty small (all the di package classes are
~26K when compiled), and it seems like it was worth the effort (vs.
just using Guice for instance).
Now will try to find time to define a Cayenne stack based on the DI,
instead of the old Configuration:
https://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-di/src/main/java/org/apache/cayenne/runtime/
Andrus
On Nov 15, 2009, at 11:57 PM, Andrus Adamchik wrote:
Just for kicks wrote a simple DI container for Cayenne. I checked it
in partially to sanbdox folder until the ASF SVN repo went down (http://monitoring.apache.org/
), so I'll commit the rest on Monday, or whenever SVN becomes
available.
This no-frills DI container took me only a couple of hours to write
(it borrows some Guice API, but implementation is all mine). It
supports
* annotation-based field dependency injection
* binding interfaces to implementation classes via fluent API
* binding interfaces to "provider" (same as "factory") classes
* merging multiple DI "modules".
The whole thing is only 14K after compilation (so it beats all full
featured DI containers in size). Of course that's because it doesn't
have all the fancy stuff (of which we'll add at least a few more
things) such as constructor injection, dependency cycle resolving,
dynamic interface proxies, bound object lifecycle, integration with
Spring, etc. Since we are not planning a general purpose container,
we might survive without most of those.
Here is how the current Configuration class might look like when it
is based on DI:
public class Configuration {
private Injector injector;
public Configuration() {
this(new CayenneModule());
}
public Configuration(Module... modules) {
this.injector = DIBootstrap.createInjector(modules);
}
public DataChannel getDataChannel() {
return injector.getInstance(DataChannel.class);
}
public ObjectContext getNewContext() {
return injector.getInstance(ObjectContext.class);
}
// we may create getters for other "services" if we need to
}
And the actual configuration class (aka "module") used above:
public class CayenneModule implements Module {
public void configure(Binder binder) {
binder.bind(EventManager.class).to(EventManagerImpl.class);
binder.bind(DataChannel.class).to(DataDomain.class);
binder.bind(QueryCache.class).toProvider(LRUCacheFactory.class);
binder.bind(QueryLogger.class).toProvider(FancyLogger.class);
// an so on...
}
}
"CayenneModule" is what users can override (e.g. simply subclass),
providing alternative implementations for some services.
The next step in this prototype would be an attempt to define the
current Cayenne stack in terms of DI.
Andrus
On Oct 27, 2009, at 11:01 PM, Kevin Menard wrote:
On Sun, Oct 25, 2009 at 5:05 PM, Andrus Adamchik <[email protected]
> wrote:
And I just discovered that both Spring (3.0RC1) and Juice (trunk)
support
the annotations from this JSR. So it could make sense for us to
use these
annotations internally as well. Couldn't dig any info on the
Tapestry IoC
support for this JSR, but they are on the JSR "support group", so
at least
they are watching it.
Thiago, the Tapestry member on the support group, just learned that
it
had been approved. Howard didn't even know the JSR existed. There's
no discussion on adding in the annotation support to Tapestry IoC and
I suspect it will happen, but Tapestry is behind the ball on that
one.
--
Kevin
