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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
