Re: IOC container

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sat Nov 21 2009 - 16:49:42 EST

  • Next message: Andrus Adamchik: "Re: IOC container"

    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 <andru..bjectstyle.org
    >> > 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
    >>
    >
    >



    This archive was generated by hypermail 2.0.0 : Sat Nov 21 2009 - 16:50:20 EST