You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Berin Loritsch <bl...@apache.org> on 2003/06/17 18:04:33 UTC
Official Collaboration?
I posed the question to the Avalon guys about oficially collaborating
with the Log4J team regarding the future direction of LogKit and Log4J.
The major thing is that the Avalon team wants to focus on their core
art which is the Framework and its containers, not the Logging toolkit.
As a breif history for those who don't know, Avalon LogKit was created
by Peter Donald and introduced prior to Log4J's acceptance to Apache.
Avalon did need a proper logging tool, and at the time, Peter's
contribution seemed the best road to take. There have been attempts to
make one logging toolkit in the past, but they have failed for various
reasons. One of the chief reasons is that the Avalon team was not
ready at that time to cooperate.
Over the years, both Log4J and LogKit learned from each other. There
were different basic philosophies regarding how to use the loggers,
but I think they can be resolved. Log4J has always lead the feature
list, and LogKit has always remained small and compact (Log4J is 345k
and LogKit is 85k).
Nicola Ken turned me on to the fact that Ceki was interested in getting
us to work together. To that end, I want to lay down what the Avalon
team would like to see (which I think is reasonable):
* The Logger instance does not combine factory and logging logic
together.
- For systems where IOC is important (like Avalon), the Logger has
a pure concept, and it cannot be obtained by other means.
- For systems where static a factory is important, like Jakarta
Commons, another class can provide that access (preferably in
a separate JAR)
- If the factory is never used, then we have better control in
complex classloader enabled systems.
* The concept of a micro-jar would be entertained.
- LogKit is small because it does not have any direct configuration
logic or other utilities.
- When 25% of the size handles 80% or more of the needs, then most
systems should be able to optimize for what they really want/need.
* All the log targets that LogKit has should be available in some
form with Log4J (which I think is the case already).
I really don't think these are all that demanding, and we would
like to help in the process if possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Official Collaboration?
Posted by Berin Loritsch <bl...@apache.org>.
Ceki Gülcü wrote:
> At 02:53 PM 6/17/2003 -0400, Berin Loritsch wrote:
>
> We don't have Memory, I mean a MemoryAppender. What is the use case
> for a MemoryAppender?
>
> Actually, the SMTPAppender is based on a cyclic buffer that sends off
> an email when a triggering event occurs. Still that is quite different
> than LogKit's MemoryTarget.
:)
From the JavaDoc on it:
* Output LogEvents into an buffer in memory.
* At a later stage these LogEvents can be forwarded or
* pushed to another target. This pushing is triggered
* when buffer is full, the priority of a LogEvent reaches a threshold
* or when another class calls the push method.
*
* This is based on specification of MemoryHandler in Logging JSR47.
I don't recall it being used much--but there are other users besides
me.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Official Collaboration?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:53 PM 6/17/2003 -0400, Berin Loritsch wrote:
>Ceki Gülcü wrote:
>
>>Of course, nothing prevents us from adding a getChildLogger(String
>>name) to the Logger class. Would that be sufficient for your needs?
>
>For the short term, sure. Right now, the Avalon wrapper for Log4J
>uses the following code snippet:
>
>Logger getChildLogger(String subCat)
>{
> return new Log4JLogger(
> Logger.getLogger(m_logger.getName() + "." + subCat));
>}
>
>It's not pretty, but it works.
It should not be too difficult (read trivial) to add these 4 lines of
code or equivalent thereof to the Logger class.
>Not yet. I haven't looked at what is available and what is not.
>
>For the quick rundown of Avalon LogKit log targets, we have:
>
>File
>Memory
>JDBC
>JMS
>JavaMail
>Servlet
>Socket
>
>As well as some file rotation strategies.
>
>If Log4J already has all these then the last bullet point can be
>ignored.
We don't have Memory, I mean a MemoryAppender. What is the use case
for a MemoryAppender?
Actually, the SMTPAppender is based on a cyclic buffer that sends off
an email when a triggering event occurs. Still that is quite different
than LogKit's MemoryTarget.
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
In the USA the log4j manual is carried by Softpro books.
http://store.yahoo.com/softpro/2-9700369-0-8.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Official Collaboration?
Posted by Berin Loritsch <bl...@apache.org>.
Ceki Gülcü wrote:
> Hello Berin,
>
> It really great to see your post. Answers in line.
>
>
> However, as I have stated in the past both privately and publicly, we
> are ready to take the necessary steps to satisfy the Avalon
> community. Let me address the points you raised.
>
>> * The Logger instance does not combine factory and logging logic
>> together.
>> - For systems where IOC is important (like Avalon), the Logger has
>> a pure concept, and it cannot be obtained by other means.
>> - For systems where static a factory is important, like Jakarta
>> Commons, another class can provide that access (preferably in
>> a separate JAR)
>> - If the factory is never used, then we have better control in
>> complex classloader enabled systems.
>
>
> Agreed completely. With hindsight, I think the Logger (aka Category
> class) should have been an interface. This is one of my secret plans
> for log4j version 2.0, the one after 1.3. Having said that, I don't
> see how to accomplish strict IOC without removing the factory method
> Logger.getLogger(). Moreover, we cannot just break backward
> compatibility of a class as central as Logger.
:) I think that is a good thing. I understand about backwards
compatibility, and we don't want you to do that just because the
way we did it was better ;P
Seriously, we have cruft in the Framework we can't get rid of
because of back-compatibility issues.
I am thinking that the Log4J 2.0 will be point where the Avalon
team can safely deprecate LogKit.
> Of course, nothing prevents us from adding a getChildLogger(String
> name) to the Logger class. Would that be sufficient for your needs?
For the short term, sure. Right now, the Avalon wrapper for Log4J
uses the following code snippet:
Logger getChildLogger(String subCat)
{
return new Log4JLogger(
Logger.getLogger(m_logger.getName() + "." + subCat));
}
It's not pretty, but it works.
>> * The concept of a micro-jar would be entertained.
>> - LogKit is small because it does not have any direct configuration
>> logic or other utilities.
>> - When 25% of the size handles 80% or more of the needs, then most
>> systems should be able to optimize for what they really want/need.
>
> With very little work, the log4j.jar can be as small as 140K or
> so. Removing appenders and other less used components is relatively
> easy. For log4j 1.3, we have separated lf5 and chainsaw so that the
> official log4j.jar file is around 230 Kb.
That's definitely better.
>> * All the log targets that LogKit has should be available in some
>> form with Log4J (which I think is the case already).
>
> Do you have any missing component in mind?
Not yet. I haven't looked at what is available and what is not.
For the quick rundown of Avalon LogKit log targets, we have:
File
Memory
JDBC
JMS
JavaMail
Servlet
Socket
As well as some file rotation strategies.
If Log4J already has all these then the last bullet point can be
ignored.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Official Collaboration?
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Berin,
It really great to see your post. Answers in line.
At 12:04 PM 6/17/2003 -0400, Berin Loritsch wrote:
>I posed the question to the Avalon guys about oficially collaborating
>with the Log4J team regarding the future direction of LogKit and Log4J.
>The major thing is that the Avalon team wants to focus on their core
>art which is the Framework and its containers, not the Logging toolkit.
>
>As a breif history for those who don't know, Avalon LogKit was created
>by Peter Donald and introduced prior to Log4J's acceptance to Apache.
>Avalon did need a proper logging tool, and at the time, Peter's
>contribution seemed the best road to take. There have been attempts to
>make one logging toolkit in the past, but they have failed for various
>reasons. One of the chief reasons is that the Avalon team was not
>ready at that time to cooperate.
Let bygones be bygones.
>Over the years, both Log4J and LogKit learned from each other. There
>were different basic philosophies regarding how to use the loggers,
>but I think they can be resolved. Log4J has always lead the feature
>list, and LogKit has always remained small and compact (Log4J is 345k
>and LogKit is 85k).
>
>Nicola Ken turned me on to the fact that Ceki was interested in getting
>us to work together. To that end, I want to lay down what the Avalon
>team would like to see (which I think is reasonable):
I have yet to see an unreasonable demand made by our users. Your
requests are not an exception. :-)
However, as I have stated in the past both privately and publicly, we
are ready to take the necessary steps to satisfy the Avalon
community. Let me address the points you raised.
>* The Logger instance does not combine factory and logging logic
> together.
> - For systems where IOC is important (like Avalon), the Logger has
> a pure concept, and it cannot be obtained by other means.
> - For systems where static a factory is important, like Jakarta
> Commons, another class can provide that access (preferably in
> a separate JAR)
> - If the factory is never used, then we have better control in
> complex classloader enabled systems.
Agreed completely. With hindsight, I think the Logger (aka Category
class) should have been an interface. This is one of my secret plans
for log4j version 2.0, the one after 1.3. Having said that, I don't
see how to accomplish strict IOC without removing the factory method
Logger.getLogger(). Moreover, we cannot just break backward
compatibility of a class as central as Logger.
Of course, nothing prevents us from adding a getChildLogger(String
name) to the Logger class. Would that be sufficient for your needs?
>* The concept of a micro-jar would be entertained.
> - LogKit is small because it does not have any direct configuration
> logic or other utilities.
> - When 25% of the size handles 80% or more of the needs, then most
> systems should be able to optimize for what they really want/need.
With very little work, the log4j.jar can be as small as 140K or
so. Removing appenders and other less used components is relatively
easy. For log4j 1.3, we have separated lf5 and chainsaw so that the
official log4j.jar file is around 230 Kb.
>* All the log targets that LogKit has should be available in some
> form with Log4J (which I think is the case already).
Do you have any missing component in mind?
>I really don't think these are all that demanding, and we would
>like to help in the process if possible.
Sounds good.
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
In the USA the log4j manual is carried by Softpro books.
http://store.yahoo.com/softpro/2-9700369-0-8.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org