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..nject and
> Provider<T>
>
> 2009/11/16 Andrus Adamchik <andru..bjectstyle.org>
>
>> 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
>>>
>>>
>>
>
>
> --
> Andrey
This archive was generated by hypermail 2.0.0 : Mon Nov 16 2009 - 02:09:44 EST