How to log FROM an appender?
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution. I suppose there must be a better way. What would that be?
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
A technique that seems to work is to NOT declare a logger in the Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
I'm curious: what use-case is fulfilled by the additional messages generated by the appender? -- TJ On Mon, Nov 14, 2011 at 4:00 PM, Steve Cohen <scohen@javactivity.org> wrote:
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
A technique that seems to work is to NOT declare a logger in the Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
It's a JMSQueue-based appender. It was written for log4j (only recently have we switched to logback) which didn't have one. In addition to the JMS functionality, at the other end of the JMS socket sits a server application written in C with its own legacy logging system that must be catered to. This involves some special formatting and data which is neither necessary nor desirable for inclusion in the local logging that the client-side application also needs. The appender is perhaps the most convenient place to do this. However, I do suppose that I should look at the layout and custom format specifier supported by logback as a possibly better way to accomplish the same thing. But what I have seems to work. On 11/14/2011 09:37 PM, TJ Rothwell wrote:
I'm curious: what use-case is fulfilled by the additional messages generated by the appender?
-- TJ
On Mon, Nov 14, 2011 at 4:00 PM, Steve Cohen<scohen@javactivity.org> wrote:
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
A technique that seems to work is to NOT declare a logger in the Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I must be missing something. Why the need to originate new logging messages from the appender? Any status updates you could do through ContextAware methods; any custom work to the JMS Queue would occur in that appender. So I don't understand the need for creating additional logging messages. If the appender is acting as a filter so some messages can be processed by a different appender, then a filter would help. [1] I'm glad you have something that works. [1] http://logback.qos.ch/manual/filters.html -- TJ On Tue, Nov 15, 2011 at 7:39 AM, Steve Cohen <scohen@javactivity.org> wrote:
It's a JMSQueue-based appender. It was written for log4j (only recently have we switched to logback) which didn't have one. In addition to the JMS functionality, at the other end of the JMS socket sits a server application written in C with its own legacy logging system that must be catered to. This involves some special formatting and data which is neither necessary nor desirable for inclusion in the local logging that the client-side application also needs. The appender is perhaps the most convenient place to do this.
However, I do suppose that I should look at the layout and custom format specifier supported by logback as a possibly better way to accomplish the same thing. But what I have seems to work.
On 11/14/2011 09:37 PM, TJ Rothwell wrote:
I'm curious: what use-case is fulfilled by the additional messages generated by the appender?
-- TJ
On Mon, Nov 14, 2011 at 4:00 PM, Steve Cohen<scohen@javactivity.org> wrote:
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging
statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
A technique that seems to work is to NOT declare a logger in the
Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Yes, as I indicated, it's a marginal use case. But 1) logging exceptions in the JMS transmission itself 2) Since the formatting of the message for the legacy logging system is happening in the JMS appender (arguably a suboptimal design) there is a use case for trace logging for development purposes to log the output of the formatting operation. In production, this would certainly be turned off. On 11/15/2011 10:32 AM, TJ Rothwell wrote:
I must be missing something. Why the need to originate new logging messages from the appender? Any status updates you could do through ContextAware methods; any custom work to the JMS Queue would occur in that appender. So I don't understand the need for creating additional logging messages. If the appender is acting as a filter so some messages can be processed by a different appender, then a filter would help. [1]
I'm glad you have something that works.
[1] http://logback.qos.ch/manual/filters.html
-- TJ
On Tue, Nov 15, 2011 at 7:39 AM, Steve Cohen<scohen@javactivity.org> wrote:
It's a JMSQueue-based appender. It was written for log4j (only recently have we switched to logback) which didn't have one. In addition to the JMS functionality, at the other end of the JMS socket sits a server application written in C with its own legacy logging system that must be catered to. This involves some special formatting and data which is neither necessary nor desirable for inclusion in the local logging that the client-side application also needs. The appender is perhaps the most convenient place to do this.
However, I do suppose that I should look at the layout and custom format specifier supported by logback as a possibly better way to accomplish the same thing. But what I have seems to work.
On 11/14/2011 09:37 PM, TJ Rothwell wrote:
I'm curious: what use-case is fulfilled by the additional messages generated by the appender?
-- TJ
On Mon, Nov 14, 2011 at 4:00 PM, Steve Cohen<scohen@javactivity.org> wrote:
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging
statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
A technique that seems to work is to NOT declare a logger in the
Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I realize this is off topic for this mailing list, but I would very much appreciate you trying https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMEN... and in particular https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMEN... . If you do give it a try please provide feedback on the log4j developers list, not here. Ralph On Tue, Nov 15, 2011 at 10:12 AM, Steve Cohen <scohen@javactivity.org>wrote:
Yes, as I indicated, it's a marginal use case. But 1) logging exceptions in the JMS transmission itself 2) Since the formatting of the message for the legacy logging system is happening in the JMS appender (arguably a suboptimal design) there is a use case for trace logging for development purposes to log the output of the formatting operation. In production, this would certainly be turned off.
On 11/15/2011 10:32 AM, TJ Rothwell wrote:
I must be missing something. Why the need to originate new logging messages from the appender? Any status updates you could do through ContextAware methods; any custom work to the JMS Queue would occur in that appender. So I don't understand the need for creating additional logging messages. If the appender is acting as a filter so some messages can be processed by a different appender, then a filter would help. [1]
I'm glad you have something that works.
[1] http://logback.qos.ch/manual/**filters.html<http://logback.qos.ch/manual/filters.html>
-- TJ
On Tue, Nov 15, 2011 at 7:39 AM, Steve Cohen<scohen@javactivity.org> wrote:
It's a JMSQueue-based appender. It was written for log4j (only recently
have we switched to logback) which didn't have one. In addition to the JMS functionality, at the other end of the JMS socket sits a server application written in C with its own legacy logging system that must be catered to. This involves some special formatting and data which is neither necessary nor desirable for inclusion in the local logging that the client-side application also needs. The appender is perhaps the most convenient place to do this.
However, I do suppose that I should look at the layout and custom format specifier supported by logback as a possibly better way to accomplish the same thing. But what I have seems to work.
On 11/14/2011 09:37 PM, TJ Rothwell wrote:
I'm curious: what use-case is fulfilled by the additional messages
generated by the appender?
-- TJ
On Mon, Nov 14, 2011 at 4:00 PM, Steve Cohen<scohen@javactivity.org> wrote:
On 11/12/2011 04:14 PM, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging
statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________******_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/******listinfo/logback-user<http://mailman.qos.ch/mailman/****listinfo/logback-user> <http**://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> > <http:/**/mailman.qos.ch/**mailman/**listinfo/logback-**user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http://mailman.qos.ch/**mailman/listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user> >
> >
A technique that seems to work is to NOT declare a logger in the
Appender class that you want to use one from, but instead create a static logger instance somewhere that is accessible through static methods. That way the logger does not need to be created at the time of appender instantiation.
______________________________******_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/******listinfo/logback-user<http://mailman.qos.ch/mailman/****listinfo/logback-user> <http**://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user>
<http:/**/mailman.qos.ch/**mailman/**listinfo/logback-**user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http://mailman.qos.ch/**mailman/listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________****_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/****listinfo/logback-user<http://mailman.qos.ch/mailman/**listinfo/logback-user> <http:/**/mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Hi Steve, Logback components, including appenders, should use the status manager. If you look at logback code you should see invocations of addInfo, addWarn or addError methods strewn throughout the code. -- Ceki On 12.11.2011 23:14, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
On 11/16/2011 12:53 AM, Ceki Gulcu wrote:
Hi Steve,
Logback components, including appenders, should use the status manager. If you look at logback code you should see invocations of addInfo, addWarn or addError methods strewn throughout the code.
-- Ceki
On 12.11.2011 23:14, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
The call to addInfo adds the message to the Status Manager. They are available to "normal" loggers. Please look at http://logback.qos.ch/manual/configuration.html#viewingStatusMessages. Ralph On Wed, Nov 16, 2011 at 8:27 AM, Steve Cohen <scohen@javactivity.org> wrote:
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Rats. That should have read "they are not available to "normal" loggers". Ralph On Wed, Nov 16, 2011 at 9:31 AM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
The call to addInfo adds the message to the Status Manager. They are available to "normal" loggers. Please look at http://logback.qos.ch/manual/configuration.html#viewingStatusMessages.
Ralph
On Wed, Nov 16, 2011 at 8:27 AM, Steve Cohen <scohen@javactivity.org>wrote:
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
The danger of an appender producing messages is infinite recursion. 1) App creates message 2) Appender processes message a) appender forwards message (file/jms/jdbc) b) appender generates another message. If this message routes back to this appender, we have infinite recursion. If the purpose of the message is diagnostic in nature, what is wrong with having a StatusListener to output it? -- TJ On Wed, Nov 16, 2011 at 11:40 AM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
Rats. That should have read "they are not available to "normal" loggers".
Ralph
On Wed, Nov 16, 2011 at 9:31 AM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
The call to addInfo adds the message to the Status Manager. They are available to "normal" loggers. Please look at http://logback.qos.ch/manual/configuration.html#viewingStatusMessages.
Ralph
On Wed, Nov 16, 2011 at 8:27 AM, Steve Cohen <scohen@javactivity.org>wrote:
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Actually, recursion isn't really a problem and is pretty easy to handle. The problem is that you are in the middle of configuring your logging system and trying to log, so what is supposed to happen to the log event? The components to process it aren't fully in place yet. Ceki handles that by detecting the attempt to create the logger and generating a nastygram. Ralph On Wed, Nov 16, 2011 at 9:46 AM, TJ Rothwell <tj.rothwell@gmail.com> wrote:
The danger of an appender producing messages is infinite recursion.
1) App creates message 2) Appender processes message a) appender forwards message (file/jms/jdbc) b) appender generates another message. If this message routes back to this appender, we have infinite recursion.
If the purpose of the message is diagnostic in nature, what is wrong with having a StatusListener to output it?
-- TJ
On Wed, Nov 16, 2011 at 11:40 AM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
Rats. That should have read "they are not available to "normal" loggers".
Ralph
On Wed, Nov 16, 2011 at 9:31 AM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
The call to addInfo adds the message to the Status Manager. They are available to "normal" loggers. Please look at http://logback.qos.ch/manual/configuration.html#viewingStatusMessages.
Ralph
On Wed, Nov 16, 2011 at 8:27 AM, Steve Cohen <scohen@javactivity.org>wrote:
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
On 16.11.2011 18:55, ralph.goers @dslextreme.com wrote:
Actually, recursion isn't really a problem and is pretty easy to handle. The problem is that you are in the middle of configuring your logging system and trying to log, so what is supposed to happen to the log event? The components to process it aren't fully in place yet. Ceki handles that by detecting the attempt to create the logger and generating a nastygram.
Ralph
Any recursive call made to a given appender is simply ignored. No exceptions whatsoever will be thrown. Thus, although not recommended, appenders *can* make logging calls. However, the recommended approach for internal logging (messages generated by logback components) is via the StatusManager. HTH, -- Ceki
Steve, Those messages aren't sent though the appenders--instead it goes through StatusListeners. http://logback.qos.ch/manual/joran.html#statusListener -- TJ On Wed, Nov 16, 2011 at 10:27 AM, Steve Cohen <scohen@javactivity.org>wrote:
On 11/16/2011 12:53 AM, Ceki Gulcu wrote:
Hi Steve,
Logback components, including appenders, should use the status manager. If you look at logback code you should see invocations of addInfo, addWarn or addError methods strewn throughout the code.
-- Ceki
On 12.11.2011 23:14, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
On 11/16/2011 10:27 AM, Steve Cohen wrote:
On 11/16/2011 12:53 AM, Ceki Gulcu wrote:
Hi Steve,
Logback components, including appenders, should use the status manager. If you look at logback code you should see invocations of addInfo, addWarn or addError methods strewn throughout the code.
-- Ceki
On 12.11.2011 23:14, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger? _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Looking at this a little more deeply, I see that this works, in the case of the OnConsoleStatusListener, via simply writing on the console. But it seems that the level you choose to add (addInfo() vs addWarn() for example) affects only the status reported on the output device and there is no filtering available based on these "levels". Is this correct?
The default OnConsoleStatusListener doesn't have filtering, however you could create your own StatusListener that does, so that it only outputs/logs the ones coming from your appender. -- TJ On Wed, Nov 16, 2011 at 11:45 AM, Steve Cohen <scohen@javactivity.org>wrote:
On 11/16/2011 10:27 AM, Steve Cohen wrote:
On 11/16/2011 12:53 AM, Ceki Gulcu wrote:
Hi Steve,
Logback components, including appenders, should use the status manager. If you look at logback code you should see invocations of addInfo, addWarn or addError methods strewn throughout the code.
-- Ceki
On 12.11.2011 23:14, Steve Cohen wrote:
We have a custom appender that may itself need to issue logging statements. But placing a logger in such a class causes various exceptions on initialization and loading. So we are resorting to System.out.println for lack of a better solution.
I suppose there must be a better way. What would that be?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Thanks, Ceki. I am looking into this. I have a question, though. If you, for example, call addInfo() from an appender, which Logger decides whether or not to log it? The root logger? ______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Looking at this a little more deeply, I see that this works, in the case of the OnConsoleStatusListener, via simply writing on the console. But it seems that the level you choose to add (addInfo() vs addWarn() for example) affects only the status reported on the output device and there is no filtering available based on these "levels". Is this correct?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
participants (4)
-
Ceki Gulcu -
ralph.goers ＠dslextreme.com -
Steve Cohen -
TJ Rothwell