You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/09/18 17:04:25 UTC
[VOTE] Framework mods
There has been some discussion over what the Logger interface should or
should not be for the next release. I want input from the different projects
that _use_ Avalon, or would like to use it to help us make the final decision.
First, let it be known that Avalon will allways prefer LogKit as the standard
Logger--although it can provide hooks for you to add your own logger
implementations. That is what the vote is for. There are a proposed Logger
interface and Loggable interface.
We have two choices to allow for pluggable Logger implementations:
1) Simply replace the Loggable and AbstractLoggable classes with the proposed
version. This causes a backwards incompatibility, and is not preffered.
2) Deprecate Loggable and create a new interface to avoid incompatibilities.
This causes us to have to use a less than desirable interface name for
the equivalent of Loggable.
Please be advised that the changes would affect you in two ways: The origin
of the Logger interface is now org.apache.avalon.logger.Logger, and if we
alter the interface name for Loggable, you would have to implement that interface
instead. The actual client API for Logger and Abstract Logger will not change
your existing code.
The most impact will be for people who actually use the Loggable interface
directly or place the logger in a local variable. You should be able to change
the import statement for the Logger object and all will be working again.
It is generally agreed that pluggable loggers would be a good thing for Avalon,
and we should be able to provide support for Log4J and LogKit relatively easily.
Committers, please place your votes.
Users, please give your comments.
Vote for approach 1 or 2 above. If you choose method 2, please provide a suggested
name for the new interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Framework mods
Posted by Peter Donald <do...@apache.org>.
On Wed, 19 Sep 2001 01:04, Berin Loritsch wrote:
> 1) Simply replace the Loggable and AbstractLoggable classes with the
> proposed version. This causes a backwards incompatibility, and is not
> preffered.
-1 before we have stable released versions of LogKit/Framework/Excalbiur that
all interoperate.
-0 after that
> 2) Deprecate Loggable and create a new interface to avoid
> incompatibilities. This causes us to have to use a less than desirable
> interface name for the equivalent of Loggable.
-0 Unless we can think of a good name. Some examples that I have thought about
LogAware
LoggerAware
LoggingAware
LogEnabled
LoggerEnabled
LoggingEnabled
Loggerizable
Loggable2
logger2.Loggable
Ages ago I had a few people also ask if we could have the method NOT conform
to beans standards because it can sometimes get mixed up with automatic
bean-mapping systems and had to be special-cased. So instead of setLogger()
we use a new method like loggerize(), logEnable() or whatever.
I guess this is the best option *if* we can think of a new interface name
that is good but I kinda like current interface name - *sigh* ;)
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Framework mods
Posted by Peter Donald <do...@apache.org>.
On Wed, 19 Sep 2001 01:04, Berin Loritsch wrote:
> 1) Simply replace the Loggable and AbstractLoggable classes with the
> proposed version. This causes a backwards incompatibility, and is not
> preffered.
-1 before we have stable released versions of LogKit/Framework/Excalbiur that
all interoperate.
-0 after that
> 2) Deprecate Loggable and create a new interface to avoid
> incompatibilities. This causes us to have to use a less than desirable
> interface name for the equivalent of Loggable.
-0 Unless we can think of a good name. Some examples that I have thought about
LogAware
LoggerAware
LoggingAware
LogEnabled
LoggerEnabled
LoggingEnabled
Loggerizable
Loggable2
logger2.Loggable
Ages ago I had a few people also ask if we could have the method NOT conform
to beans standards because it can sometimes get mixed up with automatic
bean-mapping systems and had to be special-cased. So instead of setLogger()
we use a new method like loggerize(), logEnable() or whatever.
I guess this is the best option *if* we can think of a new interface name
that is good but I kinda like current interface name - *sigh* ;)
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Framework mods
Posted by giacomo <gi...@apache.org>.
On Tue, 18 Sep 2001, Berin Loritsch wrote:
> There has been some discussion over what the Logger interface should or
> should not be for the next release. I want input from the different projects
> that _use_ Avalon, or would like to use it to help us make the final decision.
>
> First, let it be known that Avalon will allways prefer LogKit as the standard
> Logger--although it can provide hooks for you to add your own logger
> implementations. That is what the vote is for. There are a proposed Logger
> interface and Loggable interface.
>
> We have two choices to allow for pluggable Logger implementations:
>
> 1) Simply replace the Loggable and AbstractLoggable classes with the proposed
> version. This causes a backwards incompatibility, and is not preffered.
>
> 2) Deprecate Loggable and create a new interface to avoid incompatibilities.
> This causes us to have to use a less than desirable interface name for
> the equivalent of Loggable.
+1 and Loggastenical :) No seriously I have no better name for it
(Loggable is the best I can think of). It's a pitty as the package name
doesn't give any room to play with it, too. So this leads to prefer 1)
IMHO
Giacomo
>
> Please be advised that the changes would affect you in two ways: The origin
> of the Logger interface is now org.apache.avalon.logger.Logger, and if we
> alter the interface name for Loggable, you would have to implement that interface
> instead. The actual client API for Logger and Abstract Logger will not change
> your existing code.
>
> The most impact will be for people who actually use the Loggable interface
> directly or place the logger in a local variable. You should be able to change
> the import statement for the Logger object and all will be working again.
>
> It is generally agreed that pluggable loggers would be a good thing for Avalon,
> and we should be able to provide support for Log4J and LogKit relatively easily.
>
> Committers, please place your votes.
> Users, please give your comments.
>
> Vote for approach 1 or 2 above. If you choose method 2, please provide a suggested
> name for the new interface.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] Framework mods
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 1) Simply replace the Loggable and AbstractLoggable classes with the
proposed
> version. This causes a backwards incompatibility, and is not
preffered.
I vastly prefer this. The amount of code written with Avalon is small now
compared to what it will be. I say we should go for clarity and consistency
*now*. Using org.apache.log.Logger made no sense to me and I frequently
typed org.apache.avalon.framework.logger.Logger.
Esp. since the conversion can be done with a global search & replace + some
extra stuff when creating a root component manager (obtaining a logger from
the servlet container, etc.).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Framework mods
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
>
> At 11:04 AM 9/18/2001 -0400, you wrote:
> >1) Simply replace the Loggable and AbstractLoggable classes with the proposed
> > version. This causes a backwards incompatibility, and is not preffered.
>
> I prefer this. Yes, it breaks compatibility, but I value a meaningful name
> over the break. (In my own self-centered view of the world, we have yet to
> ship our C2/Avalon product, so it won't cause me any headaches)
I hear your point, and will pass it to Avalon-dev. I want as much input as
we can.
> As another alternative, org.apache.log.Logger is a class right now, what if
> that was made into an interface and used as the basis for the new common
> logging interface? Would that alleviate the need to change any existing
> code? I may be completely off base with that thought, but I figured I'd
> toss it out there.
> -pete
I don't agree with this assessment. LogKit is it's own entity--Framework is
what is (potentially) providing a wrapper for the logging implementation.
For that reason, the wrapping interfaces/adapters need to be in Framework
and not LogKit.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Framework mods
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
>
> At 11:04 AM 9/18/2001 -0400, you wrote:
> >1) Simply replace the Loggable and AbstractLoggable classes with the proposed
> > version. This causes a backwards incompatibility, and is not preffered.
>
> I prefer this. Yes, it breaks compatibility, but I value a meaningful name
> over the break. (In my own self-centered view of the world, we have yet to
> ship our C2/Avalon product, so it won't cause me any headaches)
I hear your point, and will pass it to Avalon-dev. I want as much input as
we can.
> As another alternative, org.apache.log.Logger is a class right now, what if
> that was made into an interface and used as the basis for the new common
> logging interface? Would that alleviate the need to change any existing
> code? I may be completely off base with that thought, but I figured I'd
> toss it out there.
> -pete
I don't agree with this assessment. LogKit is it's own entity--Framework is
what is (potentially) providing a wrapper for the logging implementation.
For that reason, the wrapping interfaces/adapters need to be in Framework
and not LogKit.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Framework mods
Posted by Peter Royal <pr...@managingpartners.com>.
At 11:04 AM 9/18/2001 -0400, you wrote:
>1) Simply replace the Loggable and AbstractLoggable classes with the proposed
> version. This causes a backwards incompatibility, and is not preffered.
I prefer this. Yes, it breaks compatibility, but I value a meaningful name
over the break. (In my own self-centered view of the world, we have yet to
ship our C2/Avalon product, so it won't cause me any headaches)
As another alternative, org.apache.log.Logger is a class right now, what if
that was made into an interface and used as the basis for the new common
logging interface? Would that alleviate the need to change any existing
code? I may be completely off base with that thought, but I figured I'd
toss it out there.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Framework mods
Posted by giacomo <gi...@apache.org>.
On Tue, 18 Sep 2001, Berin Loritsch wrote:
> There has been some discussion over what the Logger interface should or
> should not be for the next release. I want input from the different projects
> that _use_ Avalon, or would like to use it to help us make the final decision.
>
> First, let it be known that Avalon will allways prefer LogKit as the standard
> Logger--although it can provide hooks for you to add your own logger
> implementations. That is what the vote is for. There are a proposed Logger
> interface and Loggable interface.
>
> We have two choices to allow for pluggable Logger implementations:
>
> 1) Simply replace the Loggable and AbstractLoggable classes with the proposed
> version. This causes a backwards incompatibility, and is not preffered.
>
> 2) Deprecate Loggable and create a new interface to avoid incompatibilities.
> This causes us to have to use a less than desirable interface name for
> the equivalent of Loggable.
+1 and Loggastenical :) No seriously I have no better name for it
(Loggable is the best I can think of). It's a pitty as the package name
doesn't give any room to play with it, too. So this leads to prefer 1)
IMHO
Giacomo
>
> Please be advised that the changes would affect you in two ways: The origin
> of the Logger interface is now org.apache.avalon.logger.Logger, and if we
> alter the interface name for Loggable, you would have to implement that interface
> instead. The actual client API for Logger and Abstract Logger will not change
> your existing code.
>
> The most impact will be for people who actually use the Loggable interface
> directly or place the logger in a local variable. You should be able to change
> the import statement for the Logger object and all will be working again.
>
> It is generally agreed that pluggable loggers would be a good thing for Avalon,
> and we should be able to provide support for Log4J and LogKit relatively easily.
>
> Committers, please place your votes.
> Users, please give your comments.
>
> Vote for approach 1 or 2 above. If you choose method 2, please provide a suggested
> name for the new interface.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org