Return-Path: Delivered-To: apmail-cayenne-dev-archive@www.apache.org Received: (qmail 79823 invoked from network); 16 Nov 2009 07:09:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Nov 2009 07:09:14 -0000 Received: (qmail 92800 invoked by uid 500); 16 Nov 2009 07:09:14 -0000 Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org Received: (qmail 92747 invoked by uid 500); 16 Nov 2009 07:09:14 -0000 Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cayenne.apache.org Delivered-To: mailing list dev@cayenne.apache.org Received: (qmail 92737 invoked by uid 99); 16 Nov 2009 07:09:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 07:09:14 +0000 X-ASF-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.78.103.231] (HELO vorsha.objectstyle.org) (208.78.103.231) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 16 Nov 2009 07:09:11 +0000 Received: (qmail 13824 invoked from network); 16 Nov 2009 07:08:50 -0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by localhost with SMTP; 16 Nov 2009 07:08:50 -0000 Message-Id: From: Andrus Adamchik To: dev@cayenne.apache.org In-Reply-To: <3219fff70911152254y5b410e65yb8e75cec583a83f2@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IOC container Date: Mon, 16 Nov 2009 09:08:49 +0200 References: <3219fff70906010809lb53131age67e865246947f90@mail.gmail.com>

<806E1194-A47C-4A5A-AE03-B70C35BCEF64@roxanemy.com> <525d8e10906030442i62101329j583ab8e68e12a5c6@mail.gmail.com> <0CFADF10-B797-4CA1-BF06-33E3B5F6489F@objectstyle.org> <7BA57AD2-4ABE-4E6F-8F96-E7FAC9044925@objectstyle.org> <7e3605160910271401h1107559fq784ba410dece4140@mail.gmail.com> <036B6634-9744-4E31-98B3-5856DCA8AC20@objectstyle.org> <3219fff70911152254y5b410e65yb8e75cec583a83f2@mail.gmail.com> X-Mailer: Apple Mail (2.936) Yeah, it's been briefly mentioned in this thread: http://markmail.org/message/xyyixpaolg45cj4x The spec jar is just 4K. The annotations that I used are compatible with it, so if during development we decide it makes sense to stay standard-compliant in this case, it won't be a problem to switch. (BTW, SVN is back up and I checked in the remaining provider code). Andrus On Nov 16, 2009, at 8:54 AM, Andrey Razumovsky wrote: > Hi, > > I'm not sure it will be helpful, but there's JSR-330 spec for that > (instead > of borrowing straightly from Guice): > http://jcp.org/aboutJava/communityprocess/final/jsr330/index.html > > It defines several useful classes and annotations, as @Inject and > Provider > > 2009/11/16 Andrus Adamchik > >> 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 > > >>> 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 >>> >>> >> > > > -- > Andrey