Vadim Gritsenko wrote:
Personally, I'd favor Avalon support for chosen container. As Ralph noted, and he is not alone, people like Avalon, and we should support it for years to come.
Well, people will like DI containers once they start using them :-)
One does not exclude the other! I'd love to have ThreadSafe Configurable Initializable component with DI, both constructors and setters. And if it supports javadoc style meta info on top of it - even better. It's called smooth migration path: support good old Avalon Components, and new trendy stuff in parallel.
So why to run two containers - one too much - if Avalon support can be implemented in new container of choice. More memory, management, and confusion overhead. And people also would ask why two containers if old is still there and is used 99% of time (and that's where you answer on my question above - what's so cool about new container - helps).
I share your opinion. It would be better to provide an Avalon compatibility layer with the new container that having the old ECM still inside.
Paint me happy :-)
Vadim
