You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Torsten Curdt <tc...@dff.st> on 2001/12/20 12:35:05 UTC
[VOTE] upgrading to LogEnabled
I want to upgrade our cocoon components to use LogEnabled
instead of Loggable. Most of them extend AbstractLoggable,
so this is no big deal. But some _implement_ Loggable.
Well, I thought "no big deal either". I changed them to
implement LogEnabled and renamed the setLogger() method
to enableLogging(). But I had to realize that LogEnabled
uses a Logger from a different package!!
avalon-dev: Can someone please explain why Logger has moved?
This is giving me some real headaches with the cocoon
integration - since cocoon still uses Loggable with
the different Logger.
Having two different Loggers around is a PITA.
Should we upgrade cocoon to LogEnabled?
If so...
a) only HEAD
b) HEAD and 2.0
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] upgrading to LogEnabled
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
> I want to upgrade our cocoon components to use LogEnabled
> instead of Loggable. Most of them extend AbstractLoggable,
> so this is no big deal. But some _implement_ Loggable.
>
> Well, I thought "no big deal either". I changed them to
> implement LogEnabled and renamed the setLogger() method
> to enableLogging(). But I had to realize that LogEnabled
> uses a Logger from a different package!!
:) I feel your pain. Among the many improvements in Excalibur,
it is on the list to ease this transition. It would also allow
Cocoon to try out different logging packages *IF* they wanted
to.
> avalon-dev: Can someone please explain why Logger has moved?
> This is giving me some real headaches with the cocoon
> integration - since cocoon still uses Loggable with
> the different Logger.
It has been deprecated--but we will continue to support it
until it is time to remove the functionality.
That being said, there are a lot of people that approached us
saying, "We would love to use Avalon for project X, unfortunately
they only use logging package Y." We thought that was a pretty
sucky reason for not being able to take advantage of a well
defined architecture (what Avalon really affords), so we created
an abstraction layer.
The abstraction layer purposely avoids configuration of the
Loggers, but encourages the propper use of them.
> Having two different Loggers around is a PITA.
:) I know. If you are using the LogEnabled interface, you will
only use the Avalon defined interface. All your children now
have to be LogEnabled (the Logger is opaque, and cannot be
downcast into the original type).
If you are using the Loggable interface, and you want to pass a
logger to a LogEnabled class, simply wrap the logger in a
LogKitLogger class:
class LegacyClass extends AbstractLoggable
{
void method()
{
LogEnabled example = new NewClass();
example.enableLogging( new LogKitLogger( getLogger() ) );
}
}
Again, we are addressing the migration issues in Excalibur.
>
> Should we upgrade cocoon to LogEnabled?
Yes, but you might want to wait until the new Excalibur is
officially released.
> If so...
>
> a) only HEAD
This would be preferred. It allows you to work against a known
implementation. This way, if any surprises crop up due to
unforseen issues (like the ones you are having), users of the
main project that want bug fixes don't have to wait until the
migration is 100% complete.
> b) HEAD and 2.0
I wouldn't.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Peter Donald <pe...@apache.org>.
On Thu, 20 Dec 2001 22:59, Torsten Curdt wrote:
> On Thu, 20 Dec 2001, Peter Donald wrote:
> > On Thu, 20 Dec 2001 22:35, Torsten Curdt wrote:
> > > avalon-dev: Can someone please explain why Logger has moved?
> > > This is giving me some real headaches with the cocoon
> > > integration - since cocoon still uses Loggable with
> > > the different Logger.
> >
> > It wasn't "moved" - it is a new class completely. The new Logger is a
> > facade so that it can be more easily integrated into existing Log system
> > (ie LogKit, Logj, custom toolkits, etc). The old logger was directly tied
> > to the LogKit library.
>
> So I assume the interface has changed,too...
Only minor changes - basically it removed the "management" interface from the
Logger object. A well behaved app probably should not have been using it
anyway so in theory most of the code should compile if you search and rpelace
the following
setLogger --> enableLogging
AbstractLoggable --> AbstractLogEnabled
Loggable --> LogEnabled
org.apache.log.Logger --> org.apache.avalon.framework.logger.Logger
The only thing you will need to change manually is where the base Logger is
created in which case you will need to wrap the org.apache.log.Logger object
in a org.apache.avalon.framework.logger.LogKitLogger
--
Cheers,
Pete
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 20 Dec 2001, Peter Donald wrote:
> On Thu, 20 Dec 2001 22:35, Torsten Curdt wrote:
> > avalon-dev: Can someone please explain why Logger has moved?
> > This is giving me some real headaches with the cocoon
> > integration - since cocoon still uses Loggable with
> > the different Logger.
>
> It wasn't "moved" - it is a new class completely. The new Logger is a facade
> so that it can be more easily integrated into existing Log system (ie LogKit,
> Logj, custom toolkits, etc). The old logger was directly tied to the LogKit
> library.
So I assume the interface has changed,too...
ok! thanks, Peter!
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] upgrading to LogEnabled
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Torsten Curdt wrote:
>
>>So.... should we upgrade cocoon to LogEnabled?
>>
>>a) only HEAD
>>b) HEAD and 2.0
>>
>>
> I think we should forget the 2.0 branch as soon as possible, so
> changing a) is sufficient.
>
> Before we vote on it, can you identify what really has to be
> changed?
>>>From my memory there is at least this:
>
> a) All components must extend AbstractLogEnabled instead
> of AbstractLoggable.
> To be precise, this changes the interface
> of each component! As both solutions provide a getLogger() method
> which points to objects with similar interfaces this is not
> really a problem unless someone relies on this interface.
>
> b) There are other place where classes are tested against Loggable,
> these can not be changed that easy as someone might have developed own
> components which are either Loggable or LogEnabled.
> So at these places we have to support both! And that might be a
> problem as you need there both loggers.
The solution that Excalibur came up with for the ExcaliburTestCase
(used for testing Avalon Components) is to provide two methods:
getLogger() returns the Loggable version
getLogEnabledLogger() returns the LogEnabled version
Keep in mind that ExcaliburComponentManager can detect which Component
uses which interface, and therefore give you protection from backwards
incompatibility...
> There might be other places as well.
>
> If noone sees a problem in a) and b) can be solved and there are
> no other interface changes required, I'm +1 on this.
>
>
>>I volunteer to do it...
>>
> Great!
>
> Carsten
>
>>--
>>Torsten
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] upgrading to LogEnabled
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> On Thu, 20 Dec 2001, Carsten Ziegeler wrote:
>
> > Torsten Curdt wrote:
> > >
> > > So.... should we upgrade cocoon to LogEnabled?
> > >
> > > a) only HEAD
> > > b) HEAD and 2.0
> > >
> > I think we should forget the 2.0 branch as soon as possible, so
> > changing a) is sufficient.
>
> That's what I thought, too
>
> > Before we vote on it, can you identify what really has to be
> > changed?
> > From my memory there is at least this:
> >
> > a) All components must extend AbstractLogEnabled instead
> > of AbstractLoggable.
> > To be precise, this changes the interface
> > of each component! As both solutions provide a getLogger() method
> > which points to objects with similar interfaces this is not
> > really a problem unless someone relies on this interface.
>
> Exactly. This should not be a problem. If someone relies on this
> specific interface. Please speak up!
>
> > b) There are other place where classes are tested against Loggable,
> > these can not be changed that easy as someone might have developed own
> > components which are either Loggable or LogEnabled.
> > So at these places we have to support both! And that might be a
> > problem as you need there both loggers.
>
> Hm... yes - this might cause some trouble and forces people to
> switch over to LogEnabled.
>
> Anyone with components out there implementing Loggable
> and who is not willing to modify them to LogEnabled?
> (should be a simple search and replace!)
>
After a little bit thinking of this problem, I think we should avoid all
places where we take over the Avalon lifecycle handling, which means
at some places we instantiate objects which implement Avalon interfaces
by hand and then initialize them in the same order Avalon would do it.
If we get rid off these situations, we void also solve the above
problem. AFAIK there are two places, the first one creating new sitemap
objects and the other one in the url and source handlers. The letter
will be solved as soon as we switch to the new url and source handlers
of avalon.
Carsten
> > There might be other places as well.
> >
> > If noone sees a problem in a) and b) can be solved and there are
> > no other interface changes required, I'm +1 on this.
>
> There are no other interface changes related to this.
> --
>
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 20 Dec 2001, Carsten Ziegeler wrote:
> Torsten Curdt wrote:
> >
> > So.... should we upgrade cocoon to LogEnabled?
> >
> > a) only HEAD
> > b) HEAD and 2.0
> >
> I think we should forget the 2.0 branch as soon as possible, so
> changing a) is sufficient.
That's what I thought, too
> Before we vote on it, can you identify what really has to be
> changed?
> From my memory there is at least this:
>
> a) All components must extend AbstractLogEnabled instead
> of AbstractLoggable.
> To be precise, this changes the interface
> of each component! As both solutions provide a getLogger() method
> which points to objects with similar interfaces this is not
> really a problem unless someone relies on this interface.
Exactly. This should not be a problem. If someone relies on this
specific interface. Please speak up!
> b) There are other place where classes are tested against Loggable,
> these can not be changed that easy as someone might have developed own
> components which are either Loggable or LogEnabled.
> So at these places we have to support both! And that might be a
> problem as you need there both loggers.
Hm... yes - this might cause some trouble and forces people to
switch over to LogEnabled.
Anyone with components out there implementing Loggable
and who is not willing to modify them to LogEnabled?
(should be a simple search and replace!)
> There might be other places as well.
>
> If noone sees a problem in a) and b) can be solved and there are
> no other interface changes required, I'm +1 on this.
There are no other interface changes related to this.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] upgrading to LogEnabled
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> So.... should we upgrade cocoon to LogEnabled?
>
> a) only HEAD
> b) HEAD and 2.0
>
I think we should forget the 2.0 branch as soon as possible, so
changing a) is sufficient.
Before we vote on it, can you identify what really has to be
changed?
>From my memory there is at least this:
a) All components must extend AbstractLogEnabled instead
of AbstractLoggable.
To be precise, this changes the interface
of each component! As both solutions provide a getLogger() method
which points to objects with similar interfaces this is not
really a problem unless someone relies on this interface.
b) There are other place where classes are tested against Loggable,
these can not be changed that easy as someone might have developed own
components which are either Loggable or LogEnabled.
So at these places we have to support both! And that might be a
problem as you need there both loggers.
There might be other places as well.
If noone sees a problem in a) and b) can be solved and there are
no other interface changes required, I'm +1 on this.
> I volunteer to do it...
Great!
Carsten
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: LogEnabled
Posted by Berin Loritsch <bl...@apache.org>.
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.
>>>>
>>>>
>>>AFAI can see the current ExcaliburComponentManager still extends
>>>AbstractLoggable instead of AbstractLogEnabled. So what about
>>>a wrapper that wrapps around the ExcaliburComponentManager to
>>>have a LogEnabled version of it? Cocoon (or other migrating projects)
>>>can then use the new LogEnabled interface.
>>>When migration is finished we can remove this iterim solution.
>>>
>>
>>In order for this to work, you will need access to a LogKit logger for
>>legacy components. It is *Impossible* to get a LogKit Logger from an
>>Avalon Logger wrapper. Really, unless you can come up with a more
>>elegant solution, I don't think that will work.
>>
>
> Hm... I don't understand where there is the problem.
> (dispite the fact that it's ugly ;)
>
> class ExcaliburComponentManager extends AbstractLoggable {
> // leave it as is
> }
>
> class LogEnabledExcaliburComponentManager extends AbstractLogEnabled
> implements ....
>
> or
>
> class LogEnabledExcaliburComponentManager extends ..someclass..
> implements LogEnabled, ....
>
> {
> final private ExcaliburComponentManager cm;
> final private org.apache.avalon.framework.logger.Logger logger;
>
> // wrap/map all methods to the cm
>
> // except enabledLogging()
> final public void enabledLogging(org.apache.avalon.framework.logger.Logger logger) {
> if (logger != null) this.logger = logger
> }
>
> // except getLogger()
> final public org.apache.avalon.framework.logger.Logger getLogger() {
> return(logger);
> }
> }
>
>
> This way old systems will use the old ExcaliburComponentManager,
> new systems the new LogEnabledExcaliburComponentManager. When
> everyone has migrated we could make ExcaliburComponentManager extend
> AbstractLoggable.
Let me make it a little more plain. Cocoon version 2.0 is now officially released.
That means that if new users write their own Components that are Loggable, you won't
be able to give them the Logger class that they need.
class LogEnabledExcaliburComponentManager extends ..someclass..
implements LogEnabled, ....
{
final private ExcaliburComponentManager cm;
final private org.apache.avalon.framework.logger.Logger logger;
// wrap/map all methods to the cm
// except enabledLogging()
final public void enabledLogging(org.apache.avalon.framework.logger.Logger logger) {
if (logger != null) this.logger = logger
}
// except getLogger()
final public org.apache.avalon.framework.logger.Logger getLogger() {
return(logger);
}
setupComponent( String role, String classname, Configuration configuration )
{
ComponentHolder holder ComponentHolder.getHolderFor( classname );
holder.enableLogging( getLogger() );
holder.configure( configuration );
m_components.put( role, holder );
}
}
Assuming that all components are LogEnabled, this would work great. However, as soon
as there is a legacy component involved, the LogEnabled Logger won't work.
How do you propose to get the Logkit Logger from the existing LogEnabled logger for this
legacy Component that is sharing resources with your system?
>
> Hm... but how do I get a org.apache.avalon.framework.logger.Logger
> to enabled logging on LogEnabled components when the old ExcaliburComponentManager
> can only give the org.apache.log.Logger?!
The ExcaliburComponentManager in CVS (both in Cocoon's Excalibur Jar and in
Excalibur's CVS) knows how to handle the LogEnabled components. It is trivial
to wrap a LogKit Logger and hand it to the child component. That work is done
for you!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
> >>>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.
> >>
> >
> > AFAI can see the current ExcaliburComponentManager still extends
> > AbstractLoggable instead of AbstractLogEnabled. So what about
> > a wrapper that wrapps around the ExcaliburComponentManager to
> > have a LogEnabled version of it? Cocoon (or other migrating projects)
> > can then use the new LogEnabled interface.
> > When migration is finished we can remove this iterim solution.
>
>
> In order for this to work, you will need access to a LogKit logger for
> legacy components. It is *Impossible* to get a LogKit Logger from an
> Avalon Logger wrapper. Really, unless you can come up with a more
> elegant solution, I don't think that will work.
Hm... I don't understand where there is the problem.
(dispite the fact that it's ugly ;)
class ExcaliburComponentManager extends AbstractLoggable {
// leave it as is
}
class LogEnabledExcaliburComponentManager extends AbstractLogEnabled
implements ....
or
class LogEnabledExcaliburComponentManager extends ..someclass..
implements LogEnabled, ....
{
final private ExcaliburComponentManager cm;
final private org.apache.avalon.framework.logger.Logger logger;
// wrap/map all methods to the cm
// except enabledLogging()
final public void enabledLogging(org.apache.avalon.framework.logger.Logger logger) {
if (logger != null) this.logger = logger
}
// except getLogger()
final public org.apache.avalon.framework.logger.Logger getLogger() {
return(logger);
}
}
This way old systems will use the old ExcaliburComponentManager,
new systems the new LogEnabledExcaliburComponentManager. When
everyone has migrated we could make ExcaliburComponentManager extend
AbstractLoggable.
> > [snip]
> >
> > ...sounds cool - do you propose to wait migrating to LogEnabled 'til the
> > rewriting is finished?
>
>
> For your components, convert. The ExcaliburComponentManager in CVS can handle
> the mixture--allowing for Legacy Components. For the root Cocoon object,
> don't convert just yet.
Hm... but how do I get a org.apache.avalon.framework.logger.Logger
to enabled logging on LogEnabled components when the old ExcaliburComponentManager
can only give the org.apache.log.Logger?!
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LogEnabled
Posted by Berin Loritsch <bl...@apache.org>.
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.
>>
>
> AFAI can see the current ExcaliburComponentManager still extends
> AbstractLoggable instead of AbstractLogEnabled. So what about
> a wrapper that wrapps around the ExcaliburComponentManager to
> have a LogEnabled version of it? Cocoon (or other migrating projects)
> can then use the new LogEnabled interface.
> When migration is finished we can remove this iterim solution.
In order for this to work, you will need access to a LogKit logger for
legacy components. It is *Impossible* to get a LogKit Logger from an
Avalon Logger wrapper. Really, unless you can come up with a more
elegant solution, I don't think that will work.
> [snip]
>
> ...sounds cool - do you propose to wait migrating to LogEnabled 'til the
> rewriting is finished?
For your components, convert. The ExcaliburComponentManager in CVS can handle
the mixture--allowing for Legacy Components. For the root Cocoon object,
don't convert just yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
> > 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.
AFAI can see the current ExcaliburComponentManager still extends
AbstractLoggable instead of AbstractLogEnabled. So what about
a wrapper that wrapps around the ExcaliburComponentManager to
have a LogEnabled version of it? Cocoon (or other migrating projects)
can then use the new LogEnabled interface.
When migration is finished we can remove this iterim solution.
> > 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.
[snip]
...sounds cool - do you propose to wait migrating to LogEnabled 'til the
rewriting is finished?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LogEnabled
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
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)
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.
for cocoon at least the
- ExcaliburComponentManager
- DefaultRoleManager
- ComponentHandler
Something like a LogEnbledExcaliburComponentManager extending
AbstractLogEnabled implenting all the ExcaliburComponentManager's
interfaces and delegating the method calls.
What do you guys think?
Any other idea?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] upgrading to LogEnabled
Posted by giacomo <gi...@apache.org>.
On Fri, 28 Dec 2001, Torsten Curdt wrote:
> > > > > > > Is the LOgKitManagement able to handle LogEnabled components?
> > > >
> > > > LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
> > > > It depend of LogKit.
> > > [snip]
> > > > > > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > > > > > would be the one who knows it for sure ;)
> > > > >
> > > > > I wrote it but I don't know if someone else had changed it to support
> > > > > LogEnabled.
> > > >
> > > > Me. ;-)
> > >
> > > Great! I will move HEAD over to LogEnabled over Xmas then.
> > >
> > > See (well,read) you guys in a few days!
> >
> > Cool. After that I need a day or two of no activity to restructure the
> > repository tree.
>
> While upgrading to LogEnabled I realized that even Excalibur still uses
> AbstractLoggable. This makes upgrading cocoon a bit more ugly.
> Having the cocoon components using LogEnabled and the excalibur components
> Loggable seems not very desireable.
>
> So I propose to wait until Excalibur has moved to LogEnabled. It's
> probably not worth the hassle right now. I'll keep the scripts and
> volunteer to do it later.
Ok, cool.
> Giacomo, if you like to restructure the repository tree now - go ahead.
Yes, I'll do it in the next few days.
> Wish you and everyone else a happy new year!
> Take care guys!
Same to you ;)
Giacomo
> --
> Torsten
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
> > > > > > Is the LOgKitManagement able to handle LogEnabled components?
> > >
> > > LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
> > > It depend of LogKit.
> > [snip]
> > > > > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > > > > would be the one who knows it for sure ;)
> > > >
> > > > I wrote it but I don't know if someone else had changed it to support
> > > > LogEnabled.
> > >
> > > Me. ;-)
> >
> > Great! I will move HEAD over to LogEnabled over Xmas then.
> >
> > See (well,read) you guys in a few days!
>
> Cool. After that I need a day or two of no activity to restructure the
> repository tree.
While upgrading to LogEnabled I realized that even Excalibur still uses
AbstractLoggable. This makes upgrading cocoon a bit more ugly.
Having the cocoon components using LogEnabled and the excalibur components
Loggable seems not very desireable.
So I propose to wait until Excalibur has moved to LogEnabled. It's
probably not worth the hassle right now. I'll keep the scripts and
volunteer to do it later.
Giacomo, if you like to restructure the repository tree now - go ahead.
Wish you and everyone else a happy new year!
Take care guys!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by giacomo <gi...@apache.org>.
On Sat, 22 Dec 2001, Torsten Curdt wrote:
> > > > > > I volunteer to do it...
> > > > >
> > > > > Is the LOgKitManagement able to handle LogEnabled components?
> >
> > LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
> > It depend of LogKit.
> [snip]
> > > > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > > > would be the one who knows it for sure ;)
> > >
> > > I wrote it but I don't know if someone else had changed it to support
> > > LogEnabled.
> >
> > Me. ;-)
>
> Great! I will move HEAD over to LogEnabled over Xmas then.
>
> See (well,read) you guys in a few days!
Cool. After that I need a day or two of no activity to restructure the
repository tree.
Giacomo
>
> Merry Xmas!!
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
> > > > > I volunteer to do it...
> > > >
> > > > Is the LOgKitManagement able to handle LogEnabled components?
>
> LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
> It depend of LogKit.
[snip]
> > > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > > would be the one who knows it for sure ;)
> >
> > I wrote it but I don't know if someone else had changed it to support
> > LogEnabled.
>
> Me. ;-)
Great! I will move HEAD over to LogEnabled over Xmas then.
See (well,read) you guys in a few days!
Merry Xmas!!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by giacomo <gi...@apache.org>.
On Sat, 22 Dec 2001, Eung-ju Park wrote:
>
> ----- Original Message -----
> From: "giacomo" <gi...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Friday, December 21, 2001 8:32 PM
> Subject: Re: [VOTE] upgrading to LogEnabled
>
>
> > On Fri, 21 Dec 2001, Torsten Curdt wrote:
> >
> > > On Thu, 20 Dec 2001, giacomo wrote:
> > > > On Thu, 20 Dec 2001, Torsten Curdt wrote:
> > > >
> > > > > So.... should we upgrade cocoon to LogEnabled?
> > > > >
> > > > > a) only HEAD
> > > > > b) HEAD and 2.0
> > > > >
> > > > > I volunteer to do it...
> > > >
> > > > Is the LOgKitManagement able to handle LogEnabled components?
>
> LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
> It depend of LogKit.
Ok, that's good enought for me ;)
>
> > > >
> > > > Giacomo
> > >
> > > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > > would be the one who knows it for sure ;)
> >
> > I wrote it but I don't know if someone else had changed it to support
> > LogEnabled.
>
> Me. ;-)
Well, that's how open source works :)
>
> >
> > > Anyway I will check this...
> >
> > Thanks, very much appreciated.
> >
> > Giacomo
> >
> > > --
> > > Torsten
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "giacomo" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, December 21, 2001 8:32 PM
Subject: Re: [VOTE] upgrading to LogEnabled
> On Fri, 21 Dec 2001, Torsten Curdt wrote:
>
> > On Thu, 20 Dec 2001, giacomo wrote:
> > > On Thu, 20 Dec 2001, Torsten Curdt wrote:
> > >
> > > > So.... should we upgrade cocoon to LogEnabled?
> > > >
> > > > a) only HEAD
> > > > b) HEAD and 2.0
> > > >
> > > > I volunteer to do it...
> > >
> > > Is the LOgKitManagement able to handle LogEnabled components?
LogKitManager itself is LogEnabled. but It manage org.apache.log.Logger.
It depend of LogKit.
> > >
> > > Giacomo
> >
> > Well, I assumed - since Loggable got deprecated... (I thought _you_
> > would be the one who knows it for sure ;)
>
> I wrote it but I don't know if someone else had changed it to support
> LogEnabled.
Me. ;-)
>
> > Anyway I will check this...
>
> Thanks, very much appreciated.
>
> Giacomo
>
> > --
> > Torsten
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by giacomo <gi...@apache.org>.
On Fri, 21 Dec 2001, Torsten Curdt wrote:
> On Thu, 20 Dec 2001, giacomo wrote:
> > On Thu, 20 Dec 2001, Torsten Curdt wrote:
> >
> > > So.... should we upgrade cocoon to LogEnabled?
> > >
> > > a) only HEAD
> > > b) HEAD and 2.0
> > >
> > > I volunteer to do it...
> >
> > Is the LOgKitManagement able to handle LogEnabled components?
> >
> > Giacomo
>
> Well, I assumed - since Loggable got deprecated... (I thought _you_
> would be the one who knows it for sure ;)
I wrote it but I don't know if someone else had changed it to support
LogEnabled.
> Anyway I will check this...
Thanks, very much appreciated.
Giacomo
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 20 Dec 2001, giacomo wrote:
> On Thu, 20 Dec 2001, Torsten Curdt wrote:
>
> > So.... should we upgrade cocoon to LogEnabled?
> >
> > a) only HEAD
> > b) HEAD and 2.0
> >
> > I volunteer to do it...
>
> Is the LOgKitManagement able to handle LogEnabled components?
>
> Giacomo
Well, I assumed - since Loggable got deprecated... (I thought _you_
would be the one who knows it for sure ;)
Anyway I will check this...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by giacomo <gi...@apache.org>.
On Thu, 20 Dec 2001, Torsten Curdt wrote:
> So.... should we upgrade cocoon to LogEnabled?
>
> a) only HEAD
> b) HEAD and 2.0
>
> I volunteer to do it...
Is the LOgKitManagement able to handle LogEnabled components?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Torsten Curdt <tc...@dff.st>.
So.... should we upgrade cocoon to LogEnabled?
a) only HEAD
b) HEAD and 2.0
I volunteer to do it...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Peter Donald <pe...@apache.org>.
On Thu, 20 Dec 2001 22:35, Torsten Curdt wrote:
> avalon-dev: Can someone please explain why Logger has moved?
> This is giving me some real headaches with the cocoon
> integration - since cocoon still uses Loggable with
> the different Logger.
It wasn't "moved" - it is a new class completely. The new Logger is a facade
so that it can be more easily integrated into existing Log system (ie LogKit,
Logj, custom toolkits, etc). The old logger was directly tied to the LogKit
library.
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] upgrading to LogEnabled
Posted by Peter Donald <pe...@apache.org>.
On Thu, 20 Dec 2001 22:35, Torsten Curdt wrote:
> avalon-dev: Can someone please explain why Logger has moved?
> This is giving me some real headaches with the cocoon
> integration - since cocoon still uses Loggable with
> the different Logger.
It wasn't "moved" - it is a new class completely. The new Logger is a facade
so that it can be more easily integrated into existing Log system (ie LogKit,
Logj, custom toolkits, etc). The old logger was directly tied to the LogKit
library.
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>