You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2004/12/09 06:49:14 UTC
Make Configurators stateless again
I mentioned this a couple of days ago in
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-
dev@logging.apache.org&msgNo=8225. JoranConfigurator had changed the
configuration pattern from:
JoranConfigurator.configure(filename)
to
JoranConfigurator config = new JoranConfigurator();
config.doConfigure(filename);
List errors = config.getErrorList();
Mark Womack's recent commits suggest that this is being extended to the
other configurators.
Making the configurator's hold on to the error list seems like a bad
idea. It would be much cleaner to keep the configurator's stateless by
allowing the user to pass in a List to receive configuration errors if
they desire them or null if they don't care.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Ceki Gülcü <ce...@qos.ch>.
At 01:55 PM 12/10/2004, you wrote:
>Hi,
>
> > As Curt's remarks demonstrate, InputStream is not a common
> > *denominator* for files, URLs.
>
>Hmm, you would think that given a File and given a URL,
>File.toURL().openStream() and URL.openStream() would be a nice commons
>denominator. It's a pattern I've used in the past with good success.
Hmm, you are right. I take my comment back.
What I mean is that if something is expected to work with a URL you
cannot assume that it will also work perfectly with an InputStream. A
URL is a handle to a protocol whereas an InputStream is a sequence of
bytes.
>However, I never had to deal with the case Curt brought up, of an XML file
>providing relative URLs. What's the use case here? Can't whoever would call
>configure(inputStream, baseUri) simply call configure(inputStream) having
>resolved the relative URI and opened a stream to the absolute one themselves?
>Do we have to bend over for this?
It's the problem of compatibility with old config files in XML which
had a DTD. It's an important issue because if we get it wrong, it will
affect all existing config files (making them incompatible with 1.3).
>I also don't think it's a big deal to have a stateful Configurator. Despite
>being only 1.2->1.3 in numbering, this is a big new release, and if there's
>significant benefit in changing Configurators to stateful, and if we document
>the new stuff well, I see no problem with it. But that's just me ;)
I am still digesting Curts recent changes. Comparatively, the
statefulness issue seems so secondary that I decided to ignore it
temporarily.
>Yoav Shapira
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 10, 2004, at 6:55 AM, Yoav Shapira wrote:
> Hi,
>
>> As Curt's remarks demonstrate, InputStream is not a common
>> *denominator* for files, URLs.
>
> Hmm, you would think that given a File and given a URL,
> File.toURL().openStream() and URL.openStream() would be a nice commons
> denominator. It's a pattern I've used in the past with good success
If you added a baseURI parameter, it would handle all of the cases and
if you really had just a binary stream and no means to resolve external
entities, you could pass null.
The usage would be:
FileInputStream stream(file);
config.doConfigure(stream, file.toURI().toString());
stream.close();
InputStream stream = url.openStream();
config.doConfigure(stream, url.toString());
>
> However, I never had to deal with the case Curt brought up, of an XML
> file
> providing relative URLs. What's the use case here? Can't whoever
> would call
> configure(inputStream, baseUri) simply call configure(inputStream)
> having
> resolved the relative URI and opened a stream to the absolute one
> themselves?
> Do we have to bend over for this?
The most common is the author of an XML configuration (or his XML
editing program) has inserted a reference to a document type
description with a relative URL. This pattern would be relatively
common in existing configuration files.
<!DOCTYPE log4j:configuration SYSTEM 'log4j.dtd'>
<log4j:configuration/>
Less common would be the author of the document using external entities
(similar to include files in C++) to modularize the configuration file.
<!DOCTYPE log4j:configuration [
<!ENTITY boilerplate SYSTEM 'boilerplate.ent'>
<!ENTITY specialchar SYSTEM 'special.ent'>
]>
<log4j:configuration>
&boilerplate;
<logger name="˜uses_special_char"/>
</log4j:configuration>
Both of these documents will fail to parse (or at least parse
correctly) unless the parser can resolve 'log4j.dtd',
'boilerplate.ent', or 'special.ent'. There is not a way to the
application to resolve the relative URL's without going into the
document before parsing. In the case of the log4j.dtd, the Joran
content handler will recognize the URL and substitute and empty stream,
but it only gets to do that after the URL has been absolutized.
If you don't want to allow configuration files to access external
entity files, you could pass a non-resolvable URI (a URN or other).
// Bad example should use something more sophisitcated but gets the
job done:
FileInputStream stream(file);
config.doConfigure(stream, "about:blank");
In this case, the DTD referencing configuration will still load since
the URI will be absolutized to "about:blank/log4j.dtd" but the entity
resolver will recognize that as the log4j DTD and substitute an empty
stream.
>
> I also don't think it's a big deal to have a stateful Configurator.
> Despite
> being only 1.2->1.3 in numbering, this is a big new release, and if
> there's
> significant benefit in changing Configurators to stateful, and if we
> document
> the new stuff well, I see no problem with it. But that's just me ;)
>
That configurators are one use only did seem to be documented fairly
well in one of the other configurators. Most of my concern involved
reuse scenarios. In my submissions for the JoranConfigurator (and for
other reasons), most of the stateful stuff migrated to JoranDocument
leaving JoranConfigurator mostly stateless except for the error list
stuff inherited from ConfigurationBase. I do think the type of API
exposed by my last JoranConfigurator pass is an improvement. You don't
have to warn people not to use it twice, totally fatal errors (like
missing config files, well-formness errors) are reported as exceptions
allowing the caller to make have fallback behavior and non-fatal errors
and warning are reported but gracefully ignored.
However, like Ceki mentioned might not be the issue of concern at the
moment. However, I did want to get it out there.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> As Curt's remarks demonstrate, InputStream is not a common
> *denominator* for files, URLs.
Hmm, you would think that given a File and given a URL,
File.toURL().openStream() and URL.openStream() would be a nice commons
denominator. It's a pattern I've used in the past with good success.
However, I never had to deal with the case Curt brought up, of an XML file
providing relative URLs. What's the use case here? Can't whoever would call
configure(inputStream, baseUri) simply call configure(inputStream) having
resolved the relative URI and opened a stream to the absolute one themselves?
Do we have to bend over for this?
I also don't think it's a big deal to have a stateful Configurator. Despite
being only 1.2->1.3 in numbering, this is a big new release, and if there's
significant benefit in changing Configurators to stateful, and if we document
the new stuff well, I see no problem with it. But that's just me ;)
Yoav Shapira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make
Configurators stateless again)
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:19 PM 12/10/2004, Niclas Hedhman wrote:
>On Saturday 11 December 2004 02:11, Curt Arnold wrote:
>
> > If PropertyConfigurator had an include mechanism, it too would need
> > some way to resolve relative file references.
>
>Sorry for butting in, and there may be a lot of what I am saying is out of
>line, but;
>
>One thing that has always bugged me is that relative references are always
>hard to determine in Log4J configurations, as they relates to current
>directory (which is often hard to predict or difficult to establish to wanted
>destinations) instead of being relative to the configuration file, which
>would have been so much nicer, more predictable, easier to explain to
>customers aso.
This is interesting but almost totally unrelated to the debate at hand.
>Cheers
>Niclas
>--
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 11 December 2004 02:11, Curt Arnold wrote:
> If PropertyConfigurator had an include mechanism, it too would need
> some way to resolve relative file references.
Sorry for butting in, and there may be a lot of what I am saying is out of
line, but;
One thing that has always bugged me is that relative references are always
hard to determine in Log4J configurations, as they relates to current
directory (which is often hard to predict or difficult to establish to wanted
destinations) instead of being relative to the configuration file, which
would have been so much nicer, more predictable, easier to explain to
customers aso.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 10, 2004, at 12:26 PM, Mark Womack wrote:
> I'll buy that.
>
> Does this problem only happen with some xml config files, or ALL xml
> config
> files? I don't use the xml include mechanism in my config files, so I
> guess
> I never encountered this. But I have not been using the new
> JoranConfigurator either. I need to get up to speed there.
The problem resolving DTD's will effect enough existing configuration
files that it can't be ignored. I don't think the external entities
example would be found in the wild, however it is something that you
are "supposed" to be able to do safely in XML.
>
> So, if xml configuration data were being pushed through a socket or a
> jms
> message, it could not include any relative references, since there
> would be
> no basis to resolve them. If they did, then there would be an error
> when
> processing the data. I could live with that so long as I could
> resolve all
> the references before pushing the data and send the fully resolved
> version
> through the socket.
>
For our needs, all you would need to do would be to connect the output
event stream of an XML parser to the input event stream of an XML
serializer that writes to your payload.
I don't believe that there are any instances of relative URI's within
the document content itself that would need to be explicitly resolved.
I don't think our configuration file has anything like
<html>
...
<image href="somepicture.jpg"/>
</html>
where unless you absolutize "somepicture.jpg" before you move the HTML
document, you are likely to get no picture or, worse yet, a different
picture than the original document author intended.
The W3C's XML Base recommended provides mechanisms to deal with this
issue, but as I said, I don't think it will affect us.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make
Configurators stateless again)
Posted by Andy McBride <an...@pcmsgroup.com>.
+1
This is even more important for a library like log4j than
an end-user app.
As an advocate of the KISS principle it has been an
education to see it put into practice by the log4j
committers.
IMHO a cautious attitude should be adopted towards all
feature changes at this stage.
New functionality should now be tweaked and improved
(Receivers/RepositorySelectors/Configurators/Watchdogs)
whilst remaining as simple as possible.
I am reassured by the current level of debate on these
issues.
Kind Regards
Andy
On Fri, 10 Dec 2004 22:03:10 +0100
Ceki Gülcü <ce...@qos.ch> wrote:
>
>Good software engineers just say no! Seriously, I think
>90% of
>software engineering is about distinguishing between
>features that
>people will use and needless features that someone at
>some point
>thought would be cool to have. The worse case is when
>someone plays
>around for a while on a pet idea and then disappears
>leaving a mess
>behind.
>
>This problem is particularly severe in open-source
>projects because we
>welcome new ideas and new participants. It's really a
>tricky balance
>between encouraging participation and keeping the
>software under control.
>
>At 08:42 PM 12/10/2004, you wrote:
>>Hi,
>>Then again, I also thought XML configuration in the first
>>place was overkill ;)
>> So you can fairly safely ignore it when I say something
>>is overkill. I've
>>been in a very anti-bloat mood the past few months in all
>>the projects I work
>>on...
>>
>>Enough for today. Have a good weekend everyone,
>>
>>Yoav
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make
Configurators stateless again)
Posted by Ceki Gülcü <ce...@qos.ch>.
Good software engineers just say no! Seriously, I think 90% of
software engineering is about distinguishing between features that
people will use and needless features that someone at some point
thought would be cool to have. The worse case is when someone plays
around for a while on a pet idea and then disappears leaving a mess
behind.
This problem is particularly severe in open-source projects because we
welcome new ideas and new participants. It's really a tricky balance
between encouraging participation and keeping the software under control.
At 08:42 PM 12/10/2004, you wrote:
>Hi,
>Then again, I also thought XML configuration in the first place was
>overkill ;)
> So you can fairly safely ignore it when I say something is overkill. I've
>been in a very anti-bloat mood the past few months in all the projects I work
>on...
>
>Enough for today. Have a good weekend everyone,
>
>Yoav
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make
Configurators stateless again)
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:24 PM 12/10/2004, Niclas Hedhman wrote:
>On Saturday 11 December 2004 03:17, Curt Arnold wrote:
> >
> > <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"/>
> >
> > <configuration xmlns="http://jakarta.apache.org/log4j/"/>
> >
> > However, the current DOMConfigurator will only accept the first one.
DOMConfigurator uses the defaults, that is a non-validating, namespace
unaware parser. Moreover, it expects to the parser to hand it out an
top-most element named 'log4j:configurator'.
>Curious; Does that means that it doesn't work with
>
><logging:configuration xmlns:logging="http://jakarta.apache.org/log4j/"/>
>
>either ??
Nope, it won't work. Shocking isn't it? :-)
>Cheers
>Niclas
>--
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 11 December 2004 03:17, Curt Arnold wrote:
> The best example of this is the use of the log4j namespace prefix. Per
> the namespaces spec, these two documents should have identical
> interpretations:
>
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"/>
>
> <configuration xmlns="http://jakarta.apache.org/log4j/"/>
>
> However, the current DOMConfigurator will only accept the first one.
Curious; Does that means that it doesn't work with
<logging:configuration xmlns:logging="http://jakarta.apache.org/log4j/"/>
either ??
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
Then again, I also thought XML configuration in the first place was overkill ;)
So you can fairly safely ignore it when I say something is overkill. I've
been in a very anti-bloat mood the past few months in all the projects I work
on...
Enough for today. Have a good weekend everyone,
Yoav
--- Curt Arnold <ca...@houston.rr.com> wrote:
>
> On Dec 10, 2004, at 12:54 PM, Yoav Shapira wrote:
>
> > Hi,
> > This seems like such vast overkill. I'm not arguing the technical
> > points here,
> > I accept them all just fine. But it's configuration of a logging
> > toolkit,
> > that's all, and the current stuff has been working just fine for years
> > now.
> > How did we get into this level of in-depth discussion? ;)
> >
> > Yoav
>
>
> Most of the discussions arose from the work on the JoranConfigurator
> which is a functional replacement for the DOMConfigurator. There is
> some tension since the JoranConfigurator is in some ways a new start,
> but needs to keep some degree of compatibility with the existing
> configuration documents.
>
> Some of the issues have involved fairly established XML practice that
> wasn't properly implemented in DOMConfigurator. The mess is trying to
> work out how to do it right and maintain some backwards compatibility.
> If not done right, then we end up some log4j-specific mutant of XML.
>
> The best example of this is the use of the log4j namespace prefix. Per
> the namespaces spec, these two documents should have identical
> interpretations:
>
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"/>
>
> <configuration xmlns="http://jakarta.apache.org/log4j/"/>
>
> However, the current DOMConfigurator will only accept the first one.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 10, 2004, at 12:54 PM, Yoav Shapira wrote:
> Hi,
> This seems like such vast overkill. I'm not arguing the technical
> points here,
> I accept them all just fine. But it's configuration of a logging
> toolkit,
> that's all, and the current stuff has been working just fine for years
> now.
> How did we get into this level of in-depth discussion? ;)
>
> Yoav
Most of the discussions arose from the work on the JoranConfigurator
which is a functional replacement for the DOMConfigurator. There is
some tension since the JoranConfigurator is in some ways a new start,
but needs to keep some degree of compatibility with the existing
configuration documents.
Some of the issues have involved fairly established XML practice that
wasn't properly implemented in DOMConfigurator. The mess is trying to
work out how to do it right and maintain some backwards compatibility.
If not done right, then we end up some log4j-specific mutant of XML.
The best example of this is the use of the log4j namespace prefix. Per
the namespaces spec, these two documents should have identical
interpretations:
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"/>
<configuration xmlns="http://jakarta.apache.org/log4j/"/>
However, the current DOMConfigurator will only accept the first one.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
This seems like such vast overkill. I'm not arguing the technical points here,
I accept them all just fine. But it's configuration of a logging toolkit,
that's all, and the current stuff has been working just fine for years now.
How did we get into this level of in-depth discussion? ;)
Yoav
--- Mark Womack <wo...@adobe.com> wrote:
> I'll buy that.
>
> Does this problem only happen with some xml config files, or ALL xml config
> files? I don't use the xml include mechanism in my config files, so I guess
> I never encountered this. But I have not been using the new
> JoranConfigurator either. I need to get up to speed there.
>
> So, if xml configuration data were being pushed through a socket or a jms
> message, it could not include any relative references, since there would be
> no basis to resolve them. If they did, then there would be an error when
> processing the data. I could live with that so long as I could resolve all
> the references before pushing the data and send the fully resolved version
> through the socket.
>
> -Mark
>
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@houston.rr.com]
> Sent: Friday, December 10, 2004 10:11 AM
> To: Log4J Developers List
> Subject: Configurator.doConfigure(InputStream) (was Re: Make Configurators
> stateless again)
>
>
> On Dec 10, 2004, at 11:01 AM, Mark Womack wrote:
>
> > The baseURI issue has nothing to do with URL vs InputStream. It is
> > very XML
> > protocol specific, and I don't think that any specific protocol issue
> > should
> > be propagated into a general interface like Configurator. Not unless
> > you
> > find a way to generally represent it and it makes sense to the general
> > class/usage of Configurators.
>
> It isn't really XML specific, it just seems that way. It would effect
> any configurator that supported an include mechanism. However the XML
> configurators are the only ones at this time or in the foreseeable
> future.
>
> If PropertyConfigurator had an include mechanism, it too would need
> some way to resolve relative file references. With the extra baseURI
> parameter, PropertyConfigurator or other non-XML configuration
> mechanisms have some extra information they can just totally ignore
> until the unlikely day that they add an include mechanism.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Configurator.doConfigure(InputStream) (was Re: Make Configurators
stateless again)
Posted by Mark Womack <wo...@adobe.com>.
I'll buy that.
Does this problem only happen with some xml config files, or ALL xml config
files? I don't use the xml include mechanism in my config files, so I guess
I never encountered this. But I have not been using the new
JoranConfigurator either. I need to get up to speed there.
So, if xml configuration data were being pushed through a socket or a jms
message, it could not include any relative references, since there would be
no basis to resolve them. If they did, then there would be an error when
processing the data. I could live with that so long as I could resolve all
the references before pushing the data and send the fully resolved version
through the socket.
-Mark
-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com]
Sent: Friday, December 10, 2004 10:11 AM
To: Log4J Developers List
Subject: Configurator.doConfigure(InputStream) (was Re: Make Configurators
stateless again)
On Dec 10, 2004, at 11:01 AM, Mark Womack wrote:
> The baseURI issue has nothing to do with URL vs InputStream. It is
> very XML
> protocol specific, and I don't think that any specific protocol issue
> should
> be propagated into a general interface like Configurator. Not unless
> you
> find a way to generally represent it and it makes sense to the general
> class/usage of Configurators.
It isn't really XML specific, it just seems that way. It would effect
any configurator that supported an include mechanism. However the XML
configurators are the only ones at this time or in the foreseeable
future.
If PropertyConfigurator had an include mechanism, it too would need
some way to resolve relative file references. With the extra baseURI
parameter, PropertyConfigurator or other non-XML configuration
mechanisms have some extra information they can just totally ignore
until the unlikely day that they add an include mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 10, 2004, at 11:01 AM, Mark Womack wrote:
> The baseURI issue has nothing to do with URL vs InputStream. It is
> very XML
> protocol specific, and I don't think that any specific protocol issue
> should
> be propagated into a general interface like Configurator. Not unless
> you
> find a way to generally represent it and it makes sense to the general
> class/usage of Configurators.
It isn't really XML specific, it just seems that way. It would effect
any configurator that supported an include mechanism. However the XML
configurators are the only ones at this time or in the foreseeable
future.
If PropertyConfigurator had an include mechanism, it too would need
some way to resolve relative file references. With the extra baseURI
parameter, PropertyConfigurator or other non-XML configuration
mechanisms have some extra information they can just totally ignore
until the unlikely day that they add an include mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Make Configurators stateless again
Posted by Mark Womack <wo...@adobe.com>.
The baseURI issue has nothing to do with URL vs InputStream. It is very XML
protocol specific, and I don't think that any specific protocol issue should
be propagated into a general interface like Configurator. Not unless you
find a way to generally represent it and it makes sense to the general
class/usage of Configurators.
The fact that I can get a InputStream from a URL/File but I cannot get a URL
from an InputStream suggests, to me at least, which one is more "common".
And as I have said, there are/will be many sources that cannot be
represented as a URL. It says something that all of the current
configurators, except PropertyConfigurator, already supported
doConfigure(InputStream); I didn't have to make any changes to them when I
added the method to Configurator.
While the baseURI issue may be a big deal for the XML based configurators, I
would view this suggested interface change as a patch. If there is no other
way to deal with it, then maybe there should be a new interface,
XMLConfigurator or something. Then only the XML specific configurators will
be affected and very specific and useful methods can be devised.
-Mark
-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch]
Sent: Friday, December 10, 2004 2:46 AM
To: Log4J Developers List
Subject: Re: Make Configurators stateless again
At 09:29 PM 12/9/2004, Curt Arnold wrote:
>On Dec 9, 2004, at 12:32 AM, Mark Womack wrote:
>
>It looks like you were adding doConfigure(InputStream) methods to
>something configurator related. Would you consider making it
>
>doConfigure(InputStream stream, String baseURI);
>
>where baseURI may be null and is ignored for non-XML configurators. An
>XML document contains relative URI's can't be resolved without a baseURI
>(source of the recent thread on involving log4j.dtd).
Reverting Mark's change to the Configurator interface would be my
first choice.
As Curt's remarks demonstrate, InputStream is not a common
*denominator* for files, URLs.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:29 PM 12/9/2004, Curt Arnold wrote:
>On Dec 9, 2004, at 12:32 AM, Mark Womack wrote:
>
>It looks like you were adding doConfigure(InputStream) methods to
>something configurator related. Would you consider making it
>
>doConfigure(InputStream stream, String baseURI);
>
>where baseURI may be null and is ignored for non-XML configurators. An
>XML document contains relative URI's can't be resolved without a baseURI
>(source of the recent thread on involving log4j.dtd).
Reverting Mark's change to the Configurator interface would be my
first choice.
As Curt's remarks demonstrate, InputStream is not a common
*denominator* for files, URLs.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 9, 2004, at 12:32 AM, Mark Womack wrote:
> My recent commits don't have anything to do with this issue. They
> certainly don't extend the Configurator api to include a getErrorList
> method or a doConfigure method that takes a list to put errors into.
>
Sorry, I saw the new definitions of doConfigure(InputStream) and jumped
to the wrong conclusions.
It looks like you were adding doConfigure(InputStream) methods to
something configurator related. Would you consider making it
doConfigure(InputStream stream, String baseURI);
where baseURI may be null and is ignored for non-XML configurators. An
XML document contains relative URI's can't be resolved without a
baseURI (source of the recent thread on involving log4j.dtd).
> Just from this description, it appears that only JoranConfigurator has
> this "stateful" feature. Maybe a better way to handle this would be
> through a callback mechanism. Then the client could do whatever it
> pleases. Store it in a list for later use, whatever.
>
> If this is a feature one would want for all Configurators, the
> interface would need to be updated to include the method to register
> the callback.
>
Since I don't think any of the configurators are asynchronous, it just
seems simpler to pass a List than to register callbacks (which would
again make the configurator stateful).
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Make Configurators stateless again
Posted by Mark Womack <mw...@apache.org>.
My recent commits don't have anything to do with this issue. They certainly
don't extend the Configurator api to include a getErrorList method or a
doConfigure method that takes a list to put errors into.
Just from this description, it appears that only JoranConfigurator has this
"stateful" feature. Maybe a better way to handle this would be through a
callback mechanism. Then the client could do whatever it pleases. Store it
in a list for later use, whatever.
If this is a feature one would want for all Configurators, the interface
would need to be updated to include the method to register the callback.
-Mark
----- Original Message -----
From: "Curt Arnold" <ca...@apache.org>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Wednesday, December 08, 2004 9:49 PM
Subject: Make Configurators stateless again
>I mentioned this a couple of days ago in
>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-
>dev@logging.apache.org&msgNo=8225. JoranConfigurator had changed the
>configuration pattern from:
>
> JoranConfigurator.configure(filename)
>
> to
>
> JoranConfigurator config = new JoranConfigurator();
> config.doConfigure(filename);
> List errors = config.getErrorList();
>
> Mark Womack's recent commits suggest that this is being extended to the
> other configurators.
>
> Making the configurator's hold on to the error list seems like a bad
> idea. It would be much cleaner to keep the configurator's stateless by
> allowing the user to pass in a List to receive configuration errors if
> they desire them or null if they don't care.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org