[Quickfix-developers] QuickFIX/J: LogFactories in the Mina code (was re bug 155)

[Shepheard, T. (London) <Tob...@ml...>]

Steve and I were discussing the use of LogFactory implementations, due
to an issue I have with the network code being hardcoded to use the
apache commons LogFactory.

I've left the complete thread below, but the gist of it is that the
LogFactory implementation to use, and indeed other Factory
implementations such as MessageStore and Message, could be specified as
configuration settings down to the Session level if desired (see Steve's
message immediately below this one).

Can anyone add some comments or suggestions to this idea, or on the
logging setup in general?

Many thanks,
Toby

-----Original Message-----
From: Steve Bate [mailto:st...@te...]=20
Sent: 30 January 2006 14:35
To: Shepheard, Toby (London)
Subject: RE: [Bug 155] Changed - LogFactories in the Mina code


That's an interesting idea. Would you mind posting this suggestion
to the developer's list to see if other people have comments
or suggestions?

The only issues I know would be that there are places (in the
low-level message parsing, for example) where I use=20
log.isDebugEnabled() to optimize the log-related overhead when
not debugging. It might be reasonable to make this type of usage
a special case even if we implement support for a default Log.

Currently, the LogFactory implementations are not specified in
the settings file. We could add that feature and even support
different LogFactory implementation for each session. We could
do the same thing for MessageStoreFactory and MessageFactory
implementations.

Steve

> -----Original Message-----
> From: Shepheard, Toby (London)=20
> Sent: Monday, January 30, 2006 2:59 PM
> To: st...@te...
> Subject: RE: [Bug 155] Changed - LogFactories in the Mina code
>=20
> Point taken with regard to the session data not being=20
> available. How about having a LogFactory that can be passed=20
> in from the default config settings, which would be used for=20
> any logging that doesn't have an attached session?
>=20
> -----Original Message-----
> From: or...@qu...
> Sent: 30 January 2006 13:15
> To: Shepheard, Toby (London)
> Subject: [Bug 155] Changed - LogFactories in the Mina code
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> THIS MESSAGE WAS GENERATED BY THE BUGTRACKER SOFTWARE PLEASE DO NOT
> REPLY
>                               COMMENTS
>=20
> ----- Posted by tob...@ml... at 2:56 AM on 01-30-2006 -----
> The mina code (and also the old netty code) is hardcoded to always use
> the apache commons LogFactory - it would be great if it could=20
> honour the
> LogFactory passed in to the initiator/acceptor, or provide some other
> method to customise the LogFactory used.
>=20
> ----- Posted by st...@te... at 6:15 AM on 01-30-2006 -----
> +  There are a few issues here. The QuickFIX Log is session-specific
> + (even though a specific implementation might not be). There=20
> are places
> + where we need to log information but the associated QF=20
> Session is not
> + known or possibly even relevant. I've tried to use the QuickFIX Log
> + rather than a Commons Log every place where I had a QuickFIX Session
> + available, but I may have missed some spots. If so, let me=20
> know.<br />
> + <br />
> The other related issue is that parts of the code other than the
> + initiators and acceptors might need to log information and they will
> + generally not have access to the QuickFIX Log. My point is that even
> if we find a workaround for the MINA-related code, there are=20
> other places
> + where logged information might not be routed through the QF=20
> Log. Just FYI.
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------