Torsten Curdt wrote:
While migrating cocoon to LogEnabled I realized that not even
Excalibur is LogEnabled yet. So question is how to do a smooth
transition? Anyone a migration plan yet? (IMHO there should be
one before deprecating anything)
There is. Current CVS can handle LogEnabled Components--but it would
be backwards incompatible to change the interfaces that
ExcaliburComponentManager implements--especially since it is directly
manipulated by Cocoon and other Containers.
Problem is: changing excalibur will probably affect quite some
projects. Unfortunately AbstractLoggable and AbstractLogEnabled
both have a getLogger() method but return a different class.
So we cannot have a AbstractLogEnabledLoggable to make an easy
transition.
So I fear we would need a wrapper class for all public components.
What is in the works is a complete reimplementation of the Component
system. There will be a Container object that takes on the job of
containing the Components, and it takes on the job of exposing the
Components through the ComponentManager/Selector hierarchy. It also
takes care of the Configuration of the system. I haven't gotten that
far yet (I have an old Cocoon based system to make current)--but that
is the direction I am headed.
My plan is this:
1) Reimplement the Pooling infrastructure to allow for pools that are
externally managed so it can be done asynchronously. The current
PoolController forces a synchronous management.
2) Create a container implementation that is LogEnabled (it will not
work with Loggable Components so caveat emptor). The Container will
perform Configuration rewriting so that the cached Configuration
objects are in a consistent format (also allowing self-repairing
configuration files).
3) Propose a vote to make it a policy that all Components in Excalibur
can change lifecycle interfaces without being concidered backwards
incompatible--expecially since there are now automatic ways of
instantiating these objects.
Just a couple of notes regarding pooling. The Architecture I am shooting
for is a PoolManager/Pool relationship. If you want a ManagedPool, you
would obtain it from a PoolManager. An unmanaged pool can be instantiated
anywhere. Examples of unmanaged pools are a FixedSizePool, and one that
creates a new instance if the pool is empty, and adds returned instances
to the pool (this causes the pool to grow but never shrink). A ManagedPool
will have one manager for a whole group of pools. That manager provides
the proper pool sizing information and can safely reduce the size of
pools when load is not high. Another side benefit of a managed pool is
the application of an agent to the problem domain. This would allow a
smart agent to predict pool size needs based on time of day and day of
week, proper growth and shrink sizes, and enforce the min and max sizes
more efficiently than the current SoftResourceLimitingPool.
The Container will also revisit the question of SingleThreaded and Poolable.
It can be said that any SingleThreaded Component should be pooled--however
by requiring pooled classes to implement Poolable this is not a possible
solution. The more I look at it, IMO it is not valid to have a Component
that is not reusable.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
