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

_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user