-Original Message-
From: Ron Grabowski [mailto:[EMAIL PROTECTED]
Sent: 30 September 2005 21:20
To: Log4NET User
Subject: RE: Custom logging level
Didn't log4j implement this as part of their 1.2.x tree?
Guess what my next question is... :-)
log4j 1.2.12 added support for the
Mark,
Who can commit to the sandbox? Is the sandbox just a place for
committers to try things out? I don't think it is the right place to put
contributions that we are not supporting as they will just get orphaned
there.
log4j has a contrib dir in CVS. How does this work for you guys? Do you
Ron looks like a really good idea. I like the embedding of properties
into the Option string, sort of like the was C# attributes are defined.
We may need to think about how to quote or escape the contents so that
the format string can contain a comma if the user wants that. Maybe
something like
The ${foo} syntax was added as a quick fix to allow environment
variables to be used.
The preferred way of using an environment variable is to use a
PatternString with %env{foo}
file type=log4net.Util.PatternString
value=%env{OUTPATH}\log-file.txt /
However to be backward compatible we must
I think I like the use of named properties better than positional ones.
We can use reflection to set the property values as well, makes it easy
for the implementer and more descriptive to the user.
The Option property would remain the full text of the whole argument to
support backward
As far as I can see log4j is not really investing a lot of time in their
property file configuration stuff. They now have a new XML configurator
(Joran Configurator).
I can see your point about getting something working out of the box. If
we do something like this then is must work very simply
In general dealing with time zones is a bit of a nightmare (just like
text encodings). Another problem is that governments can change when and
how their time zones work and if they use daylight savings times or not.
So what is the current time zone offset for NewYork? Or the EastCoast? I
don't
true/false would be a good start but people would ask what failed:
// ???
if (log4net.Config.XmlConfigurator.Configure() == false)
{
processLog4netConfigError(log4net.Config.ConfigException);
}
What's the right thing to do with a log4net config error? Write the
message to
Indeed there are errors that don't really prevent logging and there are
errors that do. So we probably need to return a collection of errors.
But if there are errors them we probably also want to provide info and
debug messages that will help the user diagnose the errors.
The only error that we
