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

> Thoughts?
- Make ComponentCharacteristics a Java Enum instead of string 
comparison, that would be more java 5 friendly. the way it is now, it 
looks too much like a workaround.
- I think a key principle in the API should be that the characteristics 
would be extensible. The way it is now, you wire into the CAs the 
characteristics. I would suggest doing the opposite: the characteristics 
wire the CAs. So far to what I understand, a CACHE characteristic won't 
be used unless the CachingComponentAdapterFactory is in the pipeline.
My suggestion would be that the ComponentCharacteristic implements a 
method getComponentAdapterFactory(ComponentAdapterFactory parent). If 
all the characteristics handling ends up in ifs in CAs, I'm not sure how 
extensible this will be.
I would even suggest an API to configure default:
MutablePicoContainer pico = 
DefaultPicoContainer.buildContainer().with(NO_CACHE);
The main objective is that the day someone wants to write an extension, 
lets say thread local you could write something like:
MutablePicoContainer container = new DefaultPicoContainer();
container.*as(ThreadLocal)*.addComponent(ThreadLocalComponent.class);
without nothing else whereas with the current characteristics you would 
have to write:
MutablePicoContainer container = new DefaultPicoContainer(new 
ThreadLocalComponentAdapterFactory());
container.*as(ThreadLocal)*.addComponent(ThreadLocalComponent.class);
not to mention when you will have more extensions, you'll end up with 
ugly contructors and the poor end user will have to figure out the order.

And more (un)popular suggestions:
I think processing setters, getters and @Inject annotations is really 
quite different from what CAs were originally about.
CAs are like factories, they generate instances.
But setters and annotation processing comes after and just do something 
to an existing instance. And just a wild bet, there will be more and 
more annotation processing in the future. With the current CA model you 
are totally dependent on the order the CAs are configured in with their 
constructor and that wont play too well with many extensions at the same 
time (if everyone extends DefaultComponentAdapter).

Another thing: I think a pipeline model of CAFs in the container would 
make the configuration much better than delegating CAFs. Given how many 
classes extend DecoratingComponentAdapterFactory, it would be possible 
to make something much cleaner by having a specific interface for the 
pipelining CAFs (Hivemind has that as a prime concept, and it is very 
powerful and clean) and cut on inheritance, and dependence on 
constructors. Same could apply to CAs.

Erik