logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: Configurator.doConfigure(InputStream) (was Re: Make Configurators stateless again)
Date Fri, 10 Dec 2004 18:26:25 GMT
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


Mime
View raw message