avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: LogEnabled
Date Thu, 27 Dec 2001 14:19:14 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message