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 2003/06/18 15:09:51 UTC
Log4J Future and Avalon
I had an encouraging chat with the Log4J folks (Ceki in particular),
and we have some good news from the logger front. We all knew that
Log4J surpasses LogKit in the feature list. We also know that LogKit
does its job well for only 25% of the weight. We also know that
Log4J is not currently friendly to IOC with the Logger.getLogger()
call.
When I introduced these concerns, it appears that they are all
addressable, and actually being addressed. They are working hard
on Log4J 1.3 which will address the issues of one 345 KB JAR, and
the new JAR will weigh in at 210 KB--not 25% the size, but a step
in the right direction. The remaining 135 KB+ will be separated
out into two utility JARs that will add the extra functionality
that some folks will need, but not everybody.
They also expressed willingness to include the getChildLogger()
method that we have in LogKit.
The only thing that Log4J 1.3 cannot address is the factory method
(Logger.getLogger()) due to compatibility issues. At the same time,
Log4J 2.0 will address this issue. In fact Logger will not be a
class, but an interface.
I believe the best course of action is to continue to support
LogKit until Log4J 2.0 is released. However, in the mean time
we should start putting together stronger support for Log4J in
the Avalon containers. Many of our users will most likely be more
willing to work with Log4J, and it will be one less issue to worry
about.
I would also like us to help make Log4J 2.0 a reality. If there
are any volunteers who want to help in that direction, please
subscribe to the Log4J list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Agnostic logging support
Posted by Raymond DeCampo <rd...@twcny.rr.com>.
Ceki Gülcü wrote:
> At 04:23 PM 6/18/2003 +0200, you wrote:
>
>> Finally, there is the speed issue. As fast as an if.isDebugEnabled()
>> may be, we have seen that some places need a logging statement in a
>> "close loop", and this makes performance degrade.
>
>
> How is that possible? If the logging statements are disabled, then they
> are not used. Otherwise, if they are enabled, then they generate massive
> output rendering the logs useless. So placing log statements in tight
> loops is always a lose-lose proposition, or?
>
Well, I can see the value of logging in tight loops at the DEBUG level.
Even though you end up with a lot of log statements you might only be
interested in the last one (the one that failed). Perhaps a little
creative coding can alleviate the performance hit:
void doLoop()
{
if (log.isDebugEnabled())
{
for (int i = 0; i < limit; i++)
{
log.debug("i = " + i);
process(i);
}
}
else
{
for (int i = 0; i < limit; i++)
{
process(i);
}
}
}
void process(int i)
{
// loop interitor
}
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: [RT] Agnostic logging support
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ceki Gülcü wrote, On 18/06/2003 18.08:
> At 04:23 PM 6/18/2003 +0200, you wrote:
>
>> Finally, there is the speed issue. As fast as an if.isDebugEnabled()
>> may be, we have seen that some places need a logging statement in a
>> "close loop", and this makes performance degrade.
>
>
> How is that possible? If the logging statements are disabled, then they
> are not used.
Ok, it's just the if-isDebugEnabled()
> Otherwise, if they are enabled, then they generate massive
> output rendering the logs useless. So placing log statements in tight
> loops is always a lose-lose proposition, or?
SAX events. Or code that I have used that needs to collect statistical
info at times.
But WRT the other points, this is the minor.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: [RT] Agnostic logging support
Posted by Ceki Gülcü <lo...@qos.ch>.
At 04:23 PM 6/18/2003 +0200, you wrote:
>Finally, there is the speed issue. As fast as an if.isDebugEnabled() may
>be, we have seen that some places need a logging statement in a "close
>loop", and this makes performance degrade.
How is that possible? If the logging statements are disabled, then they are
not used. Otherwise, if they are enabled, then they generate massive output
rendering the logs useless. So placing log statements in tight loops is
always a lose-lose proposition, or?
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Log4J Future and Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 18 June 2003 21:09, Berin Loritsch wrote:
> I had an encouraging chat with the Log4J folks (Ceki in particular),
> and we have some good news from the logger front. We all knew that
> Log4J surpasses LogKit in the feature list. We also know that LogKit
> does its job well for only 25% of the weight. We also know that
> Log4J is not currently friendly to IOC with the Logger.getLogger()
> call.
>
> When I introduced these concerns, it appears that they are all
> addressable, and actually being addressed. They are working hard
> on Log4J 1.3 which will address the issues of one 345 KB JAR, and
> the new JAR will weigh in at 210 KB--not 25% the size, but a step
> in the right direction. The remaining 135 KB+ will be separated
> out into two utility JARs that will add the extra functionality
> that some folks will need, but not everybody.
All in all sounds very good, and I think people who look at Avalon (and Cocoon
I guess) for the first time, as I did some months ago, will be a lot less
confused.
I suggested to the Log4J community last year, to support that JDK logger calls
could be configured to be routed to Log4J. Ceki said that was a splendid
idea, but don't know if they have taken up that challange.
I don't know how that sits with your IoC, but isn't JDK Logging always
available to any Block?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log4J Future and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Raymond DeCampo wrote:
> Berin Loritsch wrote:
>
>> I had an encouraging chat with the Log4J folks (Ceki in particular),
>> and we have some good news from the logger front. We all knew that
>> Log4J surpasses LogKit in the feature list. We also know that LogKit
>> does its job well for only 25% of the weight. We also know that
>> Log4J is not currently friendly to IOC with the Logger.getLogger()
>> call.
>
>
> Stupid question time (especially since every else seems to know): What
> does IOC stand for?
Inversion of Control. I.e. parents provide all required stuff for
children. In component based systems it reigns supreme. The container
will provide the logger, configuration, etc. to the components. The
component cannot poll the container for what is available or access
information that it is not supposed to.
In logging systems, it translates to being able to get child loggers,
but not parent ones.
>> The only thing that Log4J 1.3 cannot address is the factory method
>> (Logger.getLogger()) due to compatibility issues. At the same time,
>> Log4J 2.0 will address this issue. In fact Logger will not be a
>> class, but an interface.
>>
>
> What about creating a separate interface, e.g. ILogger that Logger can
> implement? Then Logger still exists as is for backwards compatibility
> and moving forward people could use ILogger. I'm not sure of the total
> impact of this on log4j but I imagine it is doable. The simple approach
> is to make ILogger contain every public method that Logger contains and
> then to replace Logger with ILogger throughout the log4j code wherever
> possible.
Well, Avalon does have an interface that it uses (as well as the wrapper
class for Log4J).
The main question is wether it is worth it to invest in that at this
time. For Log4J 1.1 to Log4J 1.2, there was a change from Category to
Logger. I think it would be better for your users if you hold off until
2.0 for changing from Logger to something else.
:) Besides, I never liked "I" prefixes on interfaces anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Log4J Future and Avalon
Posted by Raymond DeCampo <rd...@twcny.rr.com>.
Berin Loritsch wrote:
> I had an encouraging chat with the Log4J folks (Ceki in particular),
> and we have some good news from the logger front. We all knew that
> Log4J surpasses LogKit in the feature list. We also know that LogKit
> does its job well for only 25% of the weight. We also know that
> Log4J is not currently friendly to IOC with the Logger.getLogger()
> call.
Stupid question time (especially since every else seems to know): What
does IOC stand for?
>
[snip]
>
> The only thing that Log4J 1.3 cannot address is the factory method
> (Logger.getLogger()) due to compatibility issues. At the same time,
> Log4J 2.0 will address this issue. In fact Logger will not be a
> class, but an interface.
>
What about creating a separate interface, e.g. ILogger that Logger can
implement? Then Logger still exists as is for backwards compatibility
and moving forward people could use ILogger. I'm not sure of the total
impact of this on log4j but I imagine it is doable. The simple approach
is to make ILogger contain every public method that Logger contains and
then to replace Logger with ILogger throughout the log4j code wherever
possible.
> I believe the best course of action is to continue to support
> LogKit until Log4J 2.0 is released. However, in the mean time
> we should start putting together stronger support for Log4J in
> the Avalon containers. Many of our users will most likely be more
> willing to work with Log4J, and it will be one less issue to worry
> about.
>
> I would also like us to help make Log4J 2.0 a reality. If there
> are any volunteers who want to help in that direction, please
> subscribe to the Log4J list.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: [RT] Agnostic logging support
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Milton Smith wrote, On 18/06/2003 18.23:
> --- Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>>A problem with logging libraries, is that even if I
>>only use the app
>>without needing *any* logging, I still have to
>>include the jar of the
>>logging library. And as small as it may be, it's
>>still something I'd
>>like to not distribute.
>
> One idea here. Don't use the Log4J implementation
> directly. Make an adapter layer that calls Log4J
> internally. Then your programs call the logging
> methods of your adaptors to log. The adaptors would
> compile and ship with your code. In side the adaptors
> you would use reflection to access Log4J. In this way
> you can choose to ship the Log4J jar or not. Also the
> adaptors could access other logging systems if needed.
> Since everything uses reflection there would not be
> any compile errors if any jars are not present.
Yup, I thought about this too. And that's what I did with POI.
Basically it's like conceptually embedding Jakarta Commons Logging in
every jar.
Many to which I have proposed this have not been very happy about it. :-(
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: [RT] Agnostic logging support
Posted by Milton Smith <br...@yahoo.com>.
--- Nicola Ken Barozzi <ni...@apache.org> wrote:
>
> A problem with logging libraries, is that even if I
> only use the app
> without needing *any* logging, I still have to
> include the jar of the
> logging library. And as small as it may be, it's
> still something I'd
> like to not distribute.
One idea here. Don't use the Log4J implementation
directly. Make an adapter layer that calls Log4J
internally. Then your programs call the logging
methods of your adaptors to log. The adaptors would
compile and ship with your code. In side the adaptors
you would use reflection to access Log4J. In this way
you can choose to ship the Log4J jar or not. Also the
adaptors could access other logging systems if needed.
Since everything uses reflection there would not be
any compile errors if any jars are not present.
>
> Then the problem of the logging library. Some want
> Jakarta Commons
> Logging, some JDK1.4 logging, some their system.
> Mind me, I understand
> that it's easy to make log4j output to their logging
> system, but it
> seems that some are really stuck to having to use
> their system throughout.
See above.
>
> Finally, there is the speed issue. As fast as an
> if.isDebugEnabled() may
> be, we have seen that some places need a logging
> statement in a "close
> loop", and this makes performance degrade.
To log or not to log....that is but the question.
>
> Ok, so what does all this mean?
>
> It seems that there are three aspects:
>
> 1 - jar dependency
> 2 - runtime removal of debug statements
> 3 - library dependency
>
>
> jar dependency
> --------------------------
> IE: I need to add a jar to my distro.
>
> Possible solution: have the code use a class that is
> in the JDK already,
> and add there a method to attach a logging library
> to it.
>
> Sample: a class that needs to log implements
> java.util.Observable
> a logger attaches to it as a
> java.util.Observer
>
>
>
> runtime removal of debug statements
>
------------------------------------------------------------
> IE: I need to not include all the logging statements
> in my code
>
> Possible solution: have the class files be
> preprocessed to remove all
> logging statements.
>
> Sample: the class files are preprocessed by BCEL to
> remove these method
> calls
>
>
> library dependency and runtime removal of debug
> statements
>
-------------------------------------------------------------
> IE: I need that logging library, and can't use mine
>
> Possible solution + Sample: This is a bit more
> elaborate and solves in
> one go also the previous issue. Instead of adding
> the log statement, we
> insert in the code a special comment, that a
> preprocessor then can
> convert to use the logging library we prefer.
>
> //[log] "Here is my log",exp,data,etc
>
> This needs a recompile of course. So another
> possibility would be to
> code against a common API (log4j for instance) and
> make the conversion
> possible also without a recompile.
>
> In this way, if I get a jar that has log4j as a
> dependency, and I don't
> want to log at all, or use my library, I could run
> it through the tool
> and have it transparently use my logging or none at
> all.
>
> Comments?
>
> --
> Nicola Ken Barozzi
> nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>
---------------------------------------------------------------------
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> log4j-dev-help@jakarta.apache.org
>
=====
****************************************
****************************************
** Milton Smith
** brahma_bull_sj@yahoo.com
** [Yahoo! spam to follow]
****************************************
****************************************
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
[RT] Agnostic logging support
Posted by Nicola Ken Barozzi <ni...@apache.org>.
A problem with logging libraries, is that even if I only use the app
without needing *any* logging, I still have to include the jar of the
logging library. And as small as it may be, it's still something I'd
like to not distribute.
Then the problem of the logging library. Some want Jakarta Commons
Logging, some JDK1.4 logging, some their system. Mind me, I understand
that it's easy to make log4j output to their logging system, but it
seems that some are really stuck to having to use their system throughout.
Finally, there is the speed issue. As fast as an if.isDebugEnabled() may
be, we have seen that some places need a logging statement in a "close
loop", and this makes performance degrade.
Ok, so what does all this mean?
It seems that there are three aspects:
1 - jar dependency
2 - runtime removal of debug statements
3 - library dependency
jar dependency
--------------------------
IE: I need to add a jar to my distro.
Possible solution: have the code use a class that is in the JDK already,
and add there a method to attach a logging library to it.
Sample: a class that needs to log implements java.util.Observable
a logger attaches to it as a java.util.Observer
runtime removal of debug statements
------------------------------------------------------------
IE: I need to not include all the logging statements in my code
Possible solution: have the class files be preprocessed to remove all
logging statements.
Sample: the class files are preprocessed by BCEL to remove these method
calls
library dependency and runtime removal of debug statements
-------------------------------------------------------------
IE: I need that logging library, and can't use mine
Possible solution + Sample: This is a bit more elaborate and solves in
one go also the previous issue. Instead of adding the log statement, we
insert in the code a special comment, that a preprocessor then can
convert to use the logging library we prefer.
//[log] "Here is my log",exp,data,etc
This needs a recompile of course. So another possibility would be to
code against a common API (log4j for instance) and make the conversion
possible also without a recompile.
In this way, if I get a jar that has log4j as a dependency, and I don't
want to log at all, or use my library, I could run it through the tool
and have it transparently use my logging or none at all.
Comments?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org