You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Huston <sh...@riverace.com> on 2008/10/15 02:04:57 UTC
RE: C++ - Question on how to handle logging options forLinux/Windows
Hi Alan,
> > A like the plugin sort of idea, but I can't justify the
> effort at this
> > point getting ready for M4. I am going to move the
> --log-output to the
> > platform-specific options. We can revisit this at a later point if
> > there's further interest or problems.
>
> I like the plugin idea too, and in retrospect I think Andrew's right
> about --log-output being an unfortunate mix. I'd suggest
> something like
> this: drop --log-output and have sink-specific options like
> --log-to-stderr yes|no
> --log-to-file <filename>
> --log-to-syslog yes|no
> ( and related --syslog options)
> --log-to-eventlog (eventlog parameters?)
> (and related --eventlog options)
Ok, that makes sense... And with two more-senior folks advocating, I'm
convinced.
> Sinks with simple config like file or stderr can be completely
> configured with a single option. More complicated sinks like
> syslog/eventlog can have additional configuration options.
> Everything related to a given type of sink can be included/excluded
by
> including/excluding options, not need to additionally manage the
> behavior of a "shared" option like --log-output.
>
> Steve, I'm OK with you going around the problem for now by making
> --log-output system specific, but could you raise a JIRA based on
this
> discussion so we don't lose the good intention to refactor?
> Making this
> pluggable will be straightforward once we've reorganized
sink-related
> options into dijoint sets.
Ok, here's how it will look when I check these in:
./qpidd --help
Usage: qpidd [OPTIONS]
<all non-logging output is the same, so not included here>
Logging options:
-t [ --trace ] Enables all logging
--log-enable RULE (error+) Enables logging for selected
levels
and components. RULE is in
the form
'LEVEL[+][:PATTERN]' Levels
are one
of:
trace debug info notice
warning
error critical
For example:
'--log-enable warning+' logs
all
warning, error and critical
messages.
'--log-enable debug:framing'
logs
debug messages from the
framing
namespace. This option can
be used
multiple times
--log-time yes|no (1) Include time in log messages
--log-level yes|no (1) Include severity level in
log
messages
--log-source yes|no (0) Include source file:line in
log
messages
--log-thread yes|no (0) Include thread ID in log
messages
--log-function yes|no (0) Include function signature
in log
messages
--log-prefix STRING Prefix to append to all log
messages
Logging sink options:
--log-to-stderr yes|no (1) Send logging output to
stderr
--log-to-stdout yes|no (0) Send logging output to
stdout
--log-to-file FILE Send log output to FILE.
--log-to-syslog yes|no (0) Send logging output to
syslog;
customize using
--syslog-name and
--syslog-facility
--syslog-name NAME (lt-qpidd) Name to use in syslog
messages
--syslog-facility LOG_XXX (LOG_DAEMON) Facility to use in syslog
messages
On Windows, the logging sink options will be different.
I'm going to go with this unless there are screams of outrage.
Thanks for your input... I really appreciate having more experienced
folks review things.
-Steve
RE: C++ - Question on how to handle logging options
forLinux/Windows
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2008-10-14 at 20:04 -0400, Steve Huston wrote:
> Hi Alan,
>
> > > A like the plugin sort of idea, but I can't justify the
> > effort at this
> > > point getting ready for M4. I am going to move the
> > --log-output to the
> > > platform-specific options. We can revisit this at a later point if
> > > there's further interest or problems.
> >
> > I like the plugin idea too, and in retrospect I think Andrew's right
> > about --log-output being an unfortunate mix. I'd suggest
> > something like
> > this: drop --log-output and have sink-specific options like
> > --log-to-stderr yes|no
> > --log-to-file <filename>
> > --log-to-syslog yes|no
> > ( and related --syslog options)
> > --log-to-eventlog (eventlog parameters?)
> > (and related --eventlog options)
>
> Ok, that makes sense... And with two more-senior folks advocating, I'm
> convinced.
>
> > Sinks with simple config like file or stderr can be completely
> > configured with a single option. More complicated sinks like
> > syslog/eventlog can have additional configuration options.
> > Everything related to a given type of sink can be included/excluded
> by
> > including/excluding options, not need to additionally manage the
> > behavior of a "shared" option like --log-output.
> >
> > Steve, I'm OK with you going around the problem for now by making
> > --log-output system specific, but could you raise a JIRA based on
> this
> > discussion so we don't lose the good intention to refactor?
> > Making this
> > pluggable will be straightforward once we've reorganized
> sink-related
> > options into dijoint sets.
>
> Ok, here's how it will look when I check these in:
>
> ./qpidd --help
> Usage: qpidd [OPTIONS]
>
> <all non-logging output is the same, so not included here>
>
> Logging options:
> -t [ --trace ] Enables all logging
> --log-enable RULE (error+) Enables logging for selected
> levels
> and components. RULE is in
> the form
> 'LEVEL[+][:PATTERN]' Levels
> are one
> of:
> trace debug info notice
> warning
> error critical
> For example:
> '--log-enable warning+' logs
> all
> warning, error and critical
> messages.
> '--log-enable debug:framing'
> logs
> debug messages from the
> framing
> namespace. This option can
> be used
> multiple times
> --log-time yes|no (1) Include time in log messages
> --log-level yes|no (1) Include severity level in
> log
> messages
> --log-source yes|no (0) Include source file:line in
> log
> messages
> --log-thread yes|no (0) Include thread ID in log
> messages
> --log-function yes|no (0) Include function signature
> in log
> messages
> --log-prefix STRING Prefix to append to all log
> messages
>
> Logging sink options:
> --log-to-stderr yes|no (1) Send logging output to
> stderr
> --log-to-stdout yes|no (0) Send logging output to
> stdout
> --log-to-file FILE Send log output to FILE.
> --log-to-syslog yes|no (0) Send logging output to
> syslog;
> customize using
> --syslog-name and
> --syslog-facility
> --syslog-name NAME (lt-qpidd) Name to use in syslog
> messages
> --syslog-facility LOG_XXX (LOG_DAEMON) Facility to use in syslog
> messages
>
>
> On Windows, the logging sink options will be different.
>
> I'm going to go with this unless there are screams of outrage.
>
> Thanks for your input... I really appreciate having more experienced
> folks review things.
>
> -Steve
>
That sounds spot-on to me.