Why do you care how dependencies are injected? You will just ask container for instance of given component and you don't care.If component initialization happens only in construcoter or it is constructor/setters combo or even constructor/setters + callback method it simply does not matter as this is hidden from you by container.I don't see how this is hidden from me by the container, as this is directly linked to the contracts my components have to obey so the container knows how to handle them. Am I missing something?
I mean that conatiner completly hides the details how given component is instantiated from the point of view of the user of this component
If you do:
Foo foo = lookup( Foo.class)
you don't care what's going on behind the scene
if it is
Foo foo = new FooImpl( lookup( Baa.class), lookup( Baa.class) )
Foo foo = new FooImpl( )
foo.setBaa1( lookup( Baa.class) )
Foo foo = new FooImpl( )
assignToPrivateField( foo,lookup( Baa.class), "bas" );
Certainly when you are the author of the component you need to choose your strategy and make it known to the container. That's why I wrote that when
you are writing a componet you are writing it accordingly to certain contract which must be supported by container. Any conatiner can support dozen of different contracts. Some containers are supporting only one contract and there
is no need to inform the container what's your contract using metadata, but still you might need to use meta data for insturcting container how it should aplay given contract.
So it is like you are saying:
Component A -- use constructor injection for this component
Component B -- use setter injection + use this meta data
which lists wich should be injeted
So as the author you do care hwo things work but as the user you don't.
You can also ask how many of Pico, Spring users would like to use their application without container.Three words: unit test cases. But then, what I'm arguing about here is that components should ideally not have any dependencies on the container, but directly on the services themselves, if there's need for them (for instance, you would depend on a DataSource, or a TimerService, TransactionService, whatever), but you shouldn't glue your component to the J2EE API just because you have to stick some metadata in it.
This sounds nice but is too simple to make it usable for anything more complex simply becouse in pratice components often must have well defined lifecycle.
For example they can be started/stopped/passivated/actiavted and so on.
Even pico components implement interfaces like Startable or Disposable and you have to distribute them with jar which defines those interfcases. For me the container really simplifies things becouse it controls the lifecycle of your component. Without it the code is simply much harder.
You don't wan't t do:
Foo foo = new Foo();
you just wan't to do:
Foo foo = lookup( Foo.class);
release( foo );
and you can igore the life cycle of the component container will take care of that. You don't need to know if this component implements Startable, Disposable or both. Or maybe dozen other callback methods.
That's why I want to use containers - they make my life simpler. If your component can exists without callback methods - it is fine - but not all components do.
I didn't also understod your remark regarding unit tests. Have you seen how they
are implemented for componets written for "light-weight" containers or
even for open-ejb? You are still using container for unit tests. It's nothig really scary or more difficult to write then ordinary test cases. Sometimes they are even much simpler.