You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Kevin Smith <ke...@electricanvil.com> on 2002/11/18 22:19:52 UTC
LogFactory.getLogger()
Hello -
I've been evaluating xindice for a bit now and have been pretty impressed with
it. I'm hoping to use xindice as a replacement for a rather horrid
proprietary XML storage system at work.
As I've been reading the code, I've noticed that in most places where
getLogger() is called the package of the class has been hardcoded. On other
projects, I've preferred to use reflection to obtain the logger, so that any
refactoring doesn't create inaccurate log messages. For example, I would do
the following:
private static Log log =
LogFactory.getLog(SymbolSerializer.getClass().getPackage().getName());
instead of
private static Log log = LogFactory.getLog("org.apache.xindice.util");
I'd be willing to submit patches to fix this, if this is something that people
would like to see done. I don't consider myself ready to participate in a
real way (yet :), but these kinds of changes help me understand the code.
Thanks,
Kevin
Re: LogFactory.getLogger()
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
PS- prove to me that there is *ANY* significant overhead in this, and
you'll get a shiny gold star ;-)
Kevin Ross wrote:
> the class name gets converted anyways...that's how the lookup is in
> every implementation I've ever seen.
>
> Speaking of CLASS.class, this method of obtaining a logger will yield
> a different (i.e. parent) class when utilizing inheritance.
> Therefore, without having to change the code in the parent everytime
> you subclass, I recommend
>
> Logger.getLogger(getClass()) at least, whether or not you use the
> string name is of no consequence.
>
> -Kevin
>
> Vladimir R. Bossicard wrote:
>
>>> +1 on getClass().getName(), everywhere (not just the server).
>>
>>
>> I would prefer CLASS.class to take advantage of the
>> LogFactory:getLog(Class cls) method. Why use the class's name
>> transformed into a String when the class itself is a valid option?
>>
>> -Vladimir
>>
>
Re: LogFactory.getLogger()
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
the class name gets converted anyways...that's how the lookup is in
every implementation I've ever seen.
Speaking of CLASS.class, this method of obtaining a logger will yield a
different (i.e. parent) class when utilizing inheritance. Therefore,
without having to change the code in the parent everytime you subclass,
I recommend
Logger.getLogger(getClass()) at least, whether or not you use the string
name is of no consequence.
-Kevin
Vladimir R. Bossicard wrote:
>> +1 on getClass().getName(), everywhere (not just the server).
>
>
> I would prefer CLASS.class to take advantage of the
> LogFactory:getLog(Class cls) method. Why use the class's name
> transformed into a String when the class itself is a valid option?
>
> -Vladimir
>
Re: LogFactory.getLogger()
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> +1 on getClass().getName(), everywhere (not just the server).
I would prefer CLASS.class to take advantage of the
LogFactory:getLog(Class cls) method. Why use the class's name
transformed into a String when the class itself is a valid option?
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: LogFactory.getLogger()
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
+1 on getClass().getName(), everywhere (not just the server).
I've gotten more experience with commons-logging and log4j, and it will
be very easy to turn on and off packages and classes using an xml file
for configuration. Note: (using log4j) a logger will inherit the
setting for <this>, <this package>, <parent package>, <grandparent
package>, etc, so it will be just as easy to turn the client off.
Here is an example log4j configuration (log4j.xml automatically found as
a classpath resource at /log4j.xml):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"
debug="false">
<!--
Log4J Configuration Quick Reference:
====================================
Priority order is DEBUG < INFO < WARN < ERROR < FATAL
PatternLayout conversion characters:
%c Category of the logging event
%C Fully qualified class name of the caller (example: %C{1}
would show just the class name instead of the full class name);
%d Date of the logging event (example: %d{HH:mm:ss,SSS} )
%F File name where the logging request was issued (caution:
extremely slow)
%l Location information of the caller (caution: extremely slow)
%L Line number from where the logging request was issued
(caution: extremely slow)
%m Application-supplied message
%M Method name from where the logging request was issued
(caution: extremely slow)
%n Line separator
%p Priority of the logging event
%r Number of milliseconds since the start of the application
%t Name of the thread that generated the logging event
%x Nested diagnotic context associated with the thread
%% A single percent sign
Format modifiers examples:
%20c Left pad with spaces if category is less than 20
characters long
%-20c Right pad with spaces if category is less than 20
characters long
%.30c Truncate from the beginning if category is more than
30 chars long
%20.30c Left pad 20 chars + truncate from beginning if more
than 30 chars
%-20.30c Right pad 20 chars + truncate from beginning if more
than 30 chars
Examples: "%r [%t] %-5p %c %x - %m\n"
"%-6r [%15.15t] %-5p %30.30c %x - %m\n"
-->
<appender name="console" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="[%d{HH:mm:ss.SSS}-%t][%C{1}][%-5p] - %m\n"/>
</layout>
</appender>
<category name="com.iverticalleap">
<priority value="debug"/>
</category>
<category name="com.iverticalleap.xflow.conf">
<priority value="info"/>
</category>
<root>
<priority value="info"/>
<appender-ref ref="console"/>
</root>
</log4j:configuration>
This will plugin automatically with commons-logging, so no further
coding is needed, other than the prescribed use of:
Logger.getLogger(getClass().getName());
-Kevin
Kevin Smith wrote:
>I only suggested the package approach because it looked like that was what was
>being done currently. I'm much more in favor of a class.getName() approach
>(that's what I normally do). If this is more appropriate, I'd be happy to
>re-submit the patch with that.
>
>If this isn't a welcome change right now, OK. I'll find something else to fix
>:-)
>
>--Kevin
>On Tuesday 19 November 2002 04:25 am, Vladimir R. Bossicard wrote:
>
>
>>>>LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
>>>>
>>>>
>>-1 on this one.
>>
>>CLASS.class.getPackage().getName() only returns the package's name,
>>without the classname.
>>
>>One solution would be
>>
>> LogFactory.getLog(CLASS.class)
>>
>>One idea was to have different granularities : one single logger for the
>>client side and several, finer loggers for the server side.
>>
>>I'm not a logger pro so I'm open to suggestions. But it's low low on my
>>todo list :-)
>>
>>-Vladimir
>>
>>
>
>
>
Re: LogFactory.getLogger()
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> If this isn't a welcome change right now, OK. I'll find something else to fix
> :-)
You will find a lot to do :-) Especially fixing the Javadoc... But
what would be more important is the website: I have committed the new
version but wait for review to publish it.
Can somebody do it? It should be straightforward since I copy/pasted a
lot of the pages.
You will need to install Forrest on you system to generate the
documentation.
-Vladimir
PS: do not forget to document in an howto what you are doing. It iwll
help other users.
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: LogFactory.getLogger()
Posted by Kevin Smith <ke...@electricanvil.com>.
I only suggested the package approach because it looked like that was what was
being done currently. I'm much more in favor of a class.getName() approach
(that's what I normally do). If this is more appropriate, I'd be happy to
re-submit the patch with that.
If this isn't a welcome change right now, OK. I'll find something else to fix
:-)
--Kevin
On Tuesday 19 November 2002 04:25 am, Vladimir R. Bossicard wrote:
> >>LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
>
> -1 on this one.
>
> CLASS.class.getPackage().getName() only returns the package's name,
> without the classname.
>
> One solution would be
>
> LogFactory.getLog(CLASS.class)
>
> One idea was to have different granularities : one single logger for the
> client side and several, finer loggers for the server side.
>
> I'm not a logger pro so I'm open to suggestions. But it's low low on my
> todo list :-)
>
> -Vladimir
Re: LogFactory.getLogger()
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
>>LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
-1 on this one.
CLASS.class.getPackage().getName() only returns the package's name,
without the classname.
One solution would be
LogFactory.getLog(CLASS.class)
One idea was to have different granularities : one single logger for the
client side and several, finer loggers for the server side.
I'm not a logger pro so I'm open to suggestions. But it's low low on my
todo list :-)
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: LogFactory.getLogger()
Posted by Kevin Smith <ke...@electricanvil.com>.
diff -u output attached for review.
--Kevin
On Monday 18 November 2002 09:32 pm, Kevin Smith wrote:
> Oops. That should be
>
> LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
>
> On Monday 18 November 2002 09:19 pm, Kevin Smith wrote:
> > Hello -
> >
> > I've been evaluating xindice for a bit now and have been pretty impressed
> > with it. I'm hoping to use xindice as a replacement for a rather horrid
> > proprietary XML storage system at work.
> >
> > As I've been reading the code, I've noticed that in most places where
> > getLogger() is called the package of the class has been hardcoded. On
> > other projects, I've preferred to use reflection to obtain the logger, so
> > that any refactoring doesn't create inaccurate log messages. For example,
> > I would do the following:
> >
> > private static Log log =
> > LogFactory.getLog(SymbolSerializer.getClass().getPackage().getName());
> >
> > instead of
> >
> > private static Log log = LogFactory.getLog("org.apache.xindice.util");
> >
> > I'd be willing to submit patches to fix this, if this is something that
> > people would like to see done. I don't consider myself ready to
> > participate in a real way (yet :), but these kinds of changes help me
> > understand the code.
> >
> > Thanks,
> > Kevin
Re: LogFactory.getLogger()
Posted by Kevin Smith <ke...@electricanvil.com>.
Oops. That should be
LogFactory.getLog(SymbolSerializer.class.getPackage().getName());
On Monday 18 November 2002 09:19 pm, Kevin Smith wrote:
> Hello -
>
> I've been evaluating xindice for a bit now and have been pretty impressed
> with it. I'm hoping to use xindice as a replacement for a rather horrid
> proprietary XML storage system at work.
>
> As I've been reading the code, I've noticed that in most places where
> getLogger() is called the package of the class has been hardcoded. On other
> projects, I've preferred to use reflection to obtain the logger, so that
> any refactoring doesn't create inaccurate log messages. For example, I
> would do the following:
>
> private static Log log =
> LogFactory.getLog(SymbolSerializer.getClass().getPackage().getName());
>
> instead of
>
> private static Log log = LogFactory.getLog("org.apache.xindice.util");
>
> I'd be willing to submit patches to fix this, if this is something that
> people would like to see done. I don't consider myself ready to participate
> in a real way (yet :), but these kinds of changes help me understand the
> code.
>
> Thanks,
> Kevin