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