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.
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
