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...@houston.rr.com> on 2004/12/10 19:11:06 UTC
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
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