Re: [picocontainer-dev] annotations and comments on Pico2

Weird - my spam filter consumed earlier messages than this in this  
thread.

Pico2 supports an @Inject annotation.  Its from our own package  
hierarchy, but we recommend against using it.   Someone could extend  
the functionality of the AnnotationComponentFactory class to support  
Guice's (or any other Domain's if that's their choice) annotation types.
We recommend against using it because we don't think components  
should be scarred by any classes/interfaces/exceptions from the  
container world. We have a Startable interface that breaks that  
design, but we have no choice really as there's nothing in the JDK  
for that.  Its extendable too for someone else's Startable concept.

Its easy for us to have a ComponentFactory that looks for @Singleton  
on classes, or @ThreadLocal and does the right thing.  There are no  
new apis needed for MutablePicoContainer.

I think most people's hopes for annotations can be met in their own  
domain model and some modest extending of ComponentFactory classes  
from our codebase.  Pico is all about facilitating choices without  
creating lock-in (we hope).

Thoughts?

Regards,

- Paul

On Jun 6, 2007, at 5:12 AM, Philipp Meier wrote:

> Konstantin Priblouda wrote:
>> --- "Putrycz, Erik" <[email protected]>
>> wrote:
>>> Konstantin, not sure what you mean by
>>> "unflexibility". And do you mean
>>> you rather would not have any annotations in the
>>> container?
>> I have 2 main objections to use of annotation for
>> wiring configuration
>> 1. they introduce dependency on container ( which is kind of uncool )
>
> I think adding a dependency on the container is bad, too. Using  
> annotations to model component dependencies is usefull in some  
> cases. So I suggest creating annotation types like "Inject" or  
> "Singleton" or "ThreadLocal" in the domain model and let pico  
> provide a simple api/spi to make us of this annotations.
>
> The simples form would be sth. like
>
> pico.mapAnnotationToCA(com.acme.model.ThreadLocal.class,  
> ThreadLocalCA.class)
>
>> 2. they are compiled into classes and can not be
>> changed afterwards. This can be solved by second
>> externalisable configuration system - and what value do they have  
>> afterwards?
>
> Using annotations to wire components together is often fine. Using  
> annotations for configuration is mostly bad. (my two cents).
>
> -billy


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email