SICA fails order of instantiation for dependencies

It's even worse: Verify is totally useless, since it is just delegated and the CICA does know nothing at all about the setter dependencies ...

You might consider looking at PICO-166 and PICO-165 and alot of mails on the mailing list concerning a topic I mentioned often beeing that ComponentAdapters knowing of other (and working with) ComponentAdapters makes things more complex than they need to.

IMHO the PicoContainer should be the only one doing anything with ComponentAdapter. If a ComponentAdapters wants to know if its Component is statisfied it should ask the container. If the CA wants to dependency instance it should ask the container (removes the need for a addOrderedComponentAdapter callback). Right now the ComponentAdapter is doing all the work and the PicoContainer is merely a HashMap giving away all the logic to the Adapters. He should be able to do some work.

Aslak proposed to let this "problem" rest until after v1.0 and I agreed cause I also want to have a v1.0 release.

Before "you start working on this" you might consider taking a look at my proposed solution. I never had the time to do the actual code and I don't know if that fixes all issues but it fixes the 3 most recents issues and makes lifecycle instantiation order alot more easier.

Nevertheless I'm -1 to doing this before v1.0. Don't know who uses SICA but probably we should just postpone this feature to a v1.1?

Hello Thomas,

I agree with you that the basic concept could be improved past 1.0 in a way you described earlier. But the current implementation fails basic functionality and I would rather return to a solution as it was in beta-5 than to release the current one. The conversion of SICA to a delegator was with the current Pico implementation only possible because of lacking unit tests. When we improve the complete design and remove the addOrderedComponentAdapter in past 1.0 we might also return to another solution for SICA again. And remember, the current implementation was not released at all, for the released versions SICA is still an ICA, so you don't know how this impacts our users.

If we support SICA for 1.0, we might do that as well as possible, but not with an implementation that fails such basic tests. IMHO we will gain a lot attention releasing 1.0 final and a lot more people will compare Pico with Spring.

So what I am basically saying:

• with the current Pico design it was a bad idea to make SICA a delegator
• return to a similar solution for SICA as in beta-5 at least for 1.0 final
• improve unit tests to ensure basic Pico functionality

nothing of this does mean, that it is carved in stone, but we should do our best for 1.0 final with the current "restriction" of PicoContainer itself.

Regards,
Jörg

Patch for SICA, CICA, ICA, SICAFactory and unit tests.
Aslak, please have a look at this.
Unit tests will be polished later on.

Aslak, can you have a look at this? Your latest change to CICA introduced already minor merge conflicts and I would like to close this issue as soon as possible.

Waiting for refactored SICA

Just added two dependencies for outstanding patches, that will have priority.

Updated patch for SICA refactoring, that applies again without merge conflict.

Separate patch for the unit test, that demonstrate the current design flaw. Makes validation esier.

Updated patch after new changes.

Refactoring now XStream compatiple

Go for it Jörg

Resolved.

test