> Using an InputStream is a problem since it would cause any XML
> configuration that contained external entities to fail to parse. For
> example, if you have a document like:
>
> <!DOCTYPE log4j:configuration [
> <!ENTITY stdAppenders SYSTEM 'stdAppenders.xml'>
> ]>
> <log4j:configuration>
> <!-- include standard appenders -->
> &stdAppenders;
> ...
> </log4j:configuration>
>
> This document would successfully parse when
> DOMConfigurator.configurator(File) is called but would fail on
> DOMConfigurator(InputStream) since the base path needed to resolve the
> relative file spec stdAppenders.xml is not provided. From reading the
> code, I believe that configureAndWatch would likely succeed on the
> initial configuration but would fail on any subsequent configuration.
>
> Using org.xml.sax.InputSource instead of java.io.InputStream may be one
> way to address the problem.
Hm. That implies that the Watchdog will need to be configured with what
kind of input type to give to the configurator, since InputSource will not
generically work with all configurators (like PropertyConfigurator). Or I
could add doConfigure(File) to ConfiguratorEx. That is probably better.
But another question is what is going to happen when I add HttpWatchdog and
SocketWatchdog this weekend? How would they resolve the location of the
filespec? Or would it need to specify the ENTITY in a different way, maybe
as a url?
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
|