A neat history of Avalon from the synergy pont of view. When read this way it actually shows that we have good community behaviour. The vision of the uber-container still haunts us all I guess. People are always going to try again - I guess it is a holy grail. That's fine as long as there is not a policy to do so that includes the early wind up of containers that are live and in use by real corporations.
I'm off on holiday for the weekend (Amsterdam) again. Please folks - no votes that are counted until Monday night. I'll have no connection this weekend. Last weekend, when I was in San Francisco and the days preceding it in Belgium I had very intermittent connections....
Regards,
- Paul
Sure - one container would be nice. It is not like it has not been attempted before in the past. Maybe some history is in order.
When I first got here there was one container. It sucked and few used it. We tried to make an uber-container then and failed. We tried again and failed. AT this stage phoenix was built from remanents and moved to new CVS.
Cocoon was at this stage either hardwiring management or using it's own container at this stage. Hence ECM came into existance. It was originally slated for framework.component.DefaultComponentManager but got moved to excalibur and was special purpose built for Cocoon. Before we released that we tried to integrate again and failed.
Anyways time went on. Other people came to Avalon somewhere here and may remember some of the other attempts that were made to create an ubercontainer.
We had the event based mechanisms added and some exist till today. For example the lifecycle extensions is essentially the same as what an early phoenix did to handle stages in lifecycle (except phoenix unified all lifecycle stuff through them). Today Phoenix still has some event based mechanisms (ApplicationListener) but largely they have failed and not been adopted to any great degree.
Phoenix later moved to strongly typed interceptors and that also failed.
A bit later another attempt was made to create an uber container. Some of you may recall the Container/Atlantis/Camelot packages. This was a framework centric approach and while it contributed a lot of good ideas the end result sucked. The conclusion was that the approach was fundamentally flawed. While Java has no notion of generic types it is impractical to try to implement it and required too much coupling/buy in from container writers.
More recently the ContainerKit project which was a component centric approach. It was better than last attempts but still failed because it was hard to integrate and making it flexible would mean making it unecessarily complex.
All of these problems are technical and while each little experiment ended up improving the result containers none of them was even close to being uber-container esque.
The problem lies in what responsibilities you want to define as the container;
* lifecycle?
* pooling?
* resource management?
* transaction management?
* remoting?
* distribution?
* interception?
* isolation?
* classloader management?
* policy management?
* security management?
* log management?
* instrumentation?
* integration with mx systems?
* scoping?
* staging?
* typing?
* deployment management?
etc.
Almost all of those are handled under different types of containers. Containers that are built for different purposes and different users. Considering Avalon is a generic it really needs to allow all those different kinds of scenarios and there are different containers that do all the above.
Even take a look at non-generic containers ala Tomcat it pretty much does everything sans policy, remoting and transaction management. And yet Tomcat adheres to a very specific spec where Avalons is relatively open ended.
No one could ever agree on a minimum spec and I think it would be counter productive to try to. What we can do is develope a set of utilitys and guidelines that can be used to construct container and make it easy to do. We may even be able to create a plug-in platform to configure containers via that. However I would not bet the farm on it and think it is unwise to try and do so.
If you look what has been happening in Phoenix for the last bit you will see that this is exactly what is happening.
* The extension management stuff was cleaned up and moved out and is now used by Phoenix and Merlin.
* The Logging was cleaned up and extracted so that now ECM, Phoenix and Fortress all use the same toolkit.
* XML Policy stuff was cleaned up, made container independent and moved to excalibur.
* ClassLoader management was reworked in excalibur as container independent and then reintegrated into Phoenix.
* Type management was reworked in excalibur as container independent and will eventually be reintegrated into Phoenix. A fork is integrated into Fortress, Merlin.
* Configuration validation is in the process of being cleaned up and migrated out. * JMX integration is slated for cleaning up and migration.
* Isolation management (ThreadContext + jprocess) was also developed as container independent
* Pooling is container independent and used in Fortress/Merlin and soon to be used in Phoenix.
In the future I expect to see the interceptors made container independent aswell as configuration of such artefacts.
So commonality is shared and differences are tolerated by some and encouraged by others.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
