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 Jacob Kjome <ho...@visi.com> on 2004/11/28 08:24:00 UTC
more Log4j-1.3 questions
Hi Ceki,
I'll try to address your responses to your other stuff tomorrow, but I want
to get a few more questions and comments out there now....
1. I'm getting a very weird compile error that I can't seem to explain...
[javac]
D:\myclasses\Repository\Jakarta\Log4jRelatedStuff\logging-log4j\src\java\org\apache\log4j\net\XMLSocketNode.java:50:
reference to Decoder is ambiguous, both class org.apache.log4j.spi.Decoder
in org.apache.log4j.spi and class org.apache.log4j.Decoder in
org.apache.log4j match
[javac] Decoder decoder;
There are actually 5 of these errors, all in the same XMLSocketNode class
on different lines. The thing is, I don't see another Decoder class other
than in the o.a.l.spi package. What the???? I'm using Ant-1.6.2 and
j2sdk1.4.2_06.
2. In the Log4j-1.3alpha-3.jar, there exists an
o.a.l.net.DefaultEvaluator.class file. However, I looked in CVS and there
is no corresponding source. The only one that corresponds to this is in
log4j-sandbox and it is mean to work with the IMAppender (also in the
sandbox). Do you have a few classes in your local repository that you
haven't checked in? Also, as we are moving stuff over to log4j-proper, are
we making sure to remove them from the sandbox?
3. PropertyConfigurator.configureAndWatch() was removed. However, this
method continues to exist in DOMConfigurator. Should it be removed there
as well?
4. Why was LoggingEvent.getMDC() renamed to XXgetMDC()? This caused a
compile failure in the MDCMatchFilter in the sandbox. Seems a bit
unnecessary especially with no real change in functionality that I can
see. Just a name change. What does the "XX" mean anyway?
5. ThrowableInformation no longer retains its throwable. This caused a
compile failure in the ServletContextLogAppender in the sandbox where it
does...
String s = layout.format(event);
ThrowableInformation ti = event.getThrowableInformation();
if (ti == null) {
servletContext.log(s);
} else {
servletContext.log(s, ti.getThrowable());
}
So, what's the replacement? To do something like the following?...
servletContext.log(s + ti.getThrowableStrRep());
Why not keep the transient throwable for situations like this?
I'll address the comments about the ContextJNDISelector tomorrow sometime.
BTW, anyone have working project files for Eclipse or Intellij? That would
be helpful to have in CVS, no?
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: more Log4j-1.3 questions
Posted by Jacob Kjome <ho...@visi.com>.
At 06:49 PM 11/28/2004 +0100, you wrote:
>At 08:24 AM 11/28/2004, you wrote:
>
>>Hi Ceki,
>>
>>I'll try to address your responses to your other stuff tomorrow, but I
>>want to get a few more questions and comments out there now....
>>
>>1. I'm getting a very weird compile error that I can't seem to explain...
>>
>> [javac]
>>
>D:\myclasses\Repository\Jakarta\Log4jRelatedStuff\logging-log4j\src\java\org
>\apache\log4j\net\XMLSocketNode.java:50:
>> reference to Decoder is ambiguous, both class
>> org.apache.log4j.spi.Decoder in org.apache.log4j.spi and class
>> org.apache.log4j.Decoder in org.apache.log4j match
>> [javac] Decoder decoder;
>>
>>There are actually 5 of these errors, all in the same XMLSocketNode class
>>on different lines. The thing is, I don't see another Decoder class other
>>than in the o.a.l.spi package. What the???? I'm using Ant-1.6.2 and
>>j2sdk1.4.2_06.
>
>Could it be a local issue? Did you try to clean up your classes?
Actually, I did clean. I did "ant clean" and then "ant jar" several times
yesterday with the same result you see above. You know how I fixed
it? You're going to love this. I went to bed (and left the computer on in
the original state), woke up, tried the same thing again and it compiled
fine. Now, how completely random is that!
>
>>2. In the Log4j-1.3alpha-3.jar, there exists an
>>o.a.l.net.DefaultEvaluator.class file. However, I looked in CVS and there
>>is no corresponding source. The only one that corresponds to this is in
>>log4j-sandbox and it is mean to work with the IMAppender (also in the
>>sandbox). Do you have a few classes in your local repository that you
>>haven't checked in? Also, as we are moving stuff over to log4j-proper,
>>are we making sure to remove them from the sandbox?
>
>There is a DefaultEvaluator class in SMPTAppender. It would be probably
>cleaner to place DefaultEvaluator in its own file but I'll leave it as is
>for the moment.
>
Weird, I tried searching for it with WinXP's file search and it only found
the one in the spi package...even when I did a text search within files,
not just the name of concrete files on the filesystem. I guess I won't be
trusting WinXP's search anymore!
>>3. PropertyConfigurator.configureAndWatch() was removed. However, this
>>method continues to exist in DOMConfigurator. Should it be removed there
>>as well?
>
>DOMConfigurator.configureAndWatch should be removed even if DOMConfigurator
>is already deprecated. Done.
Very good.
>
>>4. Why was LoggingEvent.getMDC() renamed to XXgetMDC()? This caused a
>>compile failure in the MDCMatchFilter in the sandbox. Seems a bit
>>unnecessary especially with no real change in functionality that I can
>>see. Just a name change. What does the "XX" mean anyway?
>
>Through LoggingEvent one can only access event 'properties' not the MDC.
>Prefixing methods with XX is my way of disabling a method without actually
>removing it. I just removed it and other unused methods with the XX prefix.
I saw that instead of removing you just commented them out. Why not just
remove them and de-clutter the classes?
>
>>5. ThrowableInformation no longer retains its throwable. This caused a
>>compile failure in the ServletContextLogAppender in the sandbox where it
>>does...
>>
>> String s = layout.format(event);
>> ThrowableInformation ti = event.getThrowableInformation();
>> if (ti == null) {
>> servletContext.log(s);
>> } else {
>> servletContext.log(s, ti.getThrowable());
>> }
>>
>>So, what's the replacement? To do something like the following?...
>
>You get each line of the stack frame as a separate string in the array
>returned by getThrowableStrRep(), that's the replacement... :-)
>
>>servletContext.log(s + ti.getThrowableStrRep());
>>
>>Why not keep the transient throwable for situations like this?
>
>The LoggingEvent code is already a little tricky, keeping the throwable is
>a needless optimization which does not simplify things.
>
Ok
>>I'll address the comments about the ContextJNDISelector tomorrow sometime.
>
>That'd be good.
>
>>BTW, anyone have working project files for Eclipse or Intellij? That
>>would be helpful to have in CVS, no?
>
>I am using Eclipse so is Paul. I am unsure about Scott and others. What do
>you mean by a working project file? Indentation conventions and like or
>something else like build classpath and library settings?
>
Yes. Adding .project and .classpath files would make it quick and easy to
get up and running in Eclipse. I guess it isn't that hard otherwise, but
it makes it that much easier.
Jake
>
>>Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: more Log4j-1.3 questions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:24 AM 11/28/2004, you wrote:
>Hi Ceki,
>
>I'll try to address your responses to your other stuff tomorrow, but I
>want to get a few more questions and comments out there now....
>
>1. I'm getting a very weird compile error that I can't seem to explain...
>
> [javac]
> D:\myclasses\Repository\Jakarta\Log4jRelatedStuff\logging-log4j\src\java\org\apache\log4j\net\XMLSocketNode.java:50:
> reference to Decoder is ambiguous, both class
> org.apache.log4j.spi.Decoder in org.apache.log4j.spi and class
> org.apache.log4j.Decoder in org.apache.log4j match
> [javac] Decoder decoder;
>
>There are actually 5 of these errors, all in the same XMLSocketNode class
>on different lines. The thing is, I don't see another Decoder class other
>than in the o.a.l.spi package. What the???? I'm using Ant-1.6.2 and
>j2sdk1.4.2_06.
Could it be a local issue? Did you try to clean up your classes?
>2. In the Log4j-1.3alpha-3.jar, there exists an
>o.a.l.net.DefaultEvaluator.class file. However, I looked in CVS and there
>is no corresponding source. The only one that corresponds to this is in
>log4j-sandbox and it is mean to work with the IMAppender (also in the
>sandbox). Do you have a few classes in your local repository that you
>haven't checked in? Also, as we are moving stuff over to log4j-proper,
>are we making sure to remove them from the sandbox?
There is a DefaultEvaluator class in SMPTAppender. It would be probably
cleaner to place DefaultEvaluator in its own file but I'll leave it as is
for the moment.
>3. PropertyConfigurator.configureAndWatch() was removed. However, this
>method continues to exist in DOMConfigurator. Should it be removed there
>as well?
DOMConfigurator.configureAndWatch should be removed even if DOMConfigurator
is already deprecated. Done.
>4. Why was LoggingEvent.getMDC() renamed to XXgetMDC()? This caused a
>compile failure in the MDCMatchFilter in the sandbox. Seems a bit
>unnecessary especially with no real change in functionality that I can
>see. Just a name change. What does the "XX" mean anyway?
Through LoggingEvent one can only access event 'properties' not the MDC.
Prefixing methods with XX is my way of disabling a method without actually
removing it. I just removed it and other unused methods with the XX prefix.
>5. ThrowableInformation no longer retains its throwable. This caused a
>compile failure in the ServletContextLogAppender in the sandbox where it
>does...
>
> String s = layout.format(event);
> ThrowableInformation ti = event.getThrowableInformation();
> if (ti == null) {
> servletContext.log(s);
> } else {
> servletContext.log(s, ti.getThrowable());
> }
>
>So, what's the replacement? To do something like the following?...
You get each line of the stack frame as a separate string in the array
returned by getThrowableStrRep(), that's the replacement... :-)
>servletContext.log(s + ti.getThrowableStrRep());
>
>Why not keep the transient throwable for situations like this?
The LoggingEvent code is already a little tricky, keeping the throwable is
a needless optimization which does not simplify things.
>I'll address the comments about the ContextJNDISelector tomorrow sometime.
That'd be good.
>BTW, anyone have working project files for Eclipse or Intellij? That
>would be helpful to have in CVS, no?
I am using Eclipse so is Paul. I am unsure about Scott and others. What do
you mean by a working project file? Indentation conventions and like or
something else like build classpath and library settings?
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org