The world of the Apache Inversion of Control containers has changed. Apache Excalibur is a new top level project which pulls together both of the Avalon Excalibur and Avalon Fortress projects. This includes two lightweight Inversion of Control containers.
- Posted by: Dion Almaer
- Posted on: June 14 2004 09:25 EDT
Read: Apache Excalibur Project Launches
View the new home page: http://excalibur.apache.org
- Apache Excalibur: New top level IoC Apache project by Neill Robbins on June 14 2004 09:53 EDT
- Apache Excalibur: New top level IoC Apache project by peter royal on June 14 2004 11:05 EDT
- Pass the aspirin will you... by Taylor Cowan on June 14 2004 11:14 EDT
I guess this is not unexpected news, seeing as Apache were one of the first with an IOC container....
I does seem to me however, that rather than labouring to produce yet another version, the good folk who are donating their time and experience to this project would be better off helping to incorporate their ideas into the other IOC frameworks which have more momentum now, such as Spring or Pico.
OK, I'm arguing from a position of ignorance here. I have not used Avalon. But time and again we see open source frameworks that all essentially do the same thing with greater or lesser success (and I'm not picking Avalon for critism necessarily. For balance, hands up those who have got a headache trying to decide which web framework is the 'best' for their particular web dev project. At least 4 of them from Apache alone.
Its just a shame that rather than co-operating to produce one or possibly two excellent frameworks we see a lot of duplication and unecessary filliblustering by committers and their advocates about which framework is 'best'.
Perhaps I'm just being naive in my belief that it should be possible to co-operate more on projects like this...
Course, as a developer, you get this stuff for free, so I guess you can't complain can you.
Just a thought.
Pass the aspirin will you...
I does seem to me however, that rather than labouring to produce yet another version, the good folk who are donating their time and experience to this project would be better off helping to incorporate their ideas into the other IOC frameworks which have more momentum now, such as Spring or Pico.One of the driving forces behind Excalibur was that Avalon itself no longer wanted to maintain these containers, and there are users with production systems that depend on them. Pico and Spring are both new, so developers that have projects that are only a year or so old are the main ones to have invested in them. The containers that will be in excalibur have been around considerably longer (2+ years), so there are users with more of an investment, and unfortunately swapping out a core container isn't always an option.
Users sometimes need an evolutionary migration path, not a revolutionary one. But the good thing about having Spring/Pico around is that they injected new ideas into the fray, and those ideas will be incorporated back into older containers.
I wholeheartedly agree. Avalon isnt even among the better IoC containers. My experience is that it is quite intrusive in its lookup semantics and interface requirements. J2EE has hinted at some of the IoC features with JNDI and JMX. I cant see the big difference in calling one lookup from another, besides the fact that JNDI is a standard. Just last week I read that Spring is integrated with HiveMind. That said, someones probably working on integrating Pico, Spring, Avalon, and HiveMind together, or building migration tools to move components from one container to another.
Avalon is not only one of the least friendly containers to use, but even the avalon developers can't seem to agree on the project's direction. Anyone who jumps on this band-wagon is surely asking entering into a Jakarta-enduced, world of pain.
\ Just last week I read that Spring is integrated with HiveMind. That said, someones probably working on integrating Pico, Spring, Avalon, and HiveMind together, or building migration tools to move components from one container to another.The point of the purer containers (HiveMind, Spring, Pico) are that the components, the code, are very transportable because they don't make use of any container-specific APIs. They are just POJOs. Using some form of injection (whether by constructor parameters or settable parameters or some other form of magic) eliminates the dependencies on the APIs of the container.
Making them work together is very simple, the integration between HiveMind and Spring is just a few lines of code.
The real differences, in terms of services, are how one tells the container about the POJOs that can be managed, and how one expresses relationships between the POJOs.
Spring has very powerful AOP built in, and has a lot of work invested in pre-built services for transaction management, Hibernate integration, a web layer, and a bunch of other stuff (more than I know about).
Pico is very, very small and very unobtrusive (if you get used to its constructor based injection).
HiveMind has services like Spring and Pico, but also has configuration data (somewhat similar to how Eclipse plugins work).