Can we take a step back? Let's look at the possibilities: 1. URI resolver: Processes a URI String, returning either the same URI or a modified/different one. Corresponds to JAXP's URIResolver and SAX's EntityResolver. Generally usable whereever we use URIs to access external resources.
2. URI to InputStream resolver: Takes a URI and returns an InputStream from where a resource (font, image etc.) can be loaded. Such a resolver could mak use of the URI resolver above before actually resolving to an InputStream. 3. URI to FopImage resolver: Basically corresponds to our FopImageFactory today. Takes an URI and provides a FopImage instance, making use of at least a (1) and optionally (2). (3) could, for example, also provide the ability to create an image on the fly (charts, barcodes, static progress indicators, whatever...). All three could be expressed as plain Java interfaces. Each for its own level of responsibility. From top to bottom the responsibilities narrow down. Wouldn't it solve any possible requirement to provide a central registry in FOP where implementations of these interfaces (all three) are provided? By default, FOP provides its own basic implementations and our customers (Cocoon for example) could plug in their SourceResolver and CatalogResolver as necessary. Actually, that was what I originally planned to do by introducing Avalon (Framework). Its Serviceable/ServiceManager pair would have provided this infrastructure (allowing easy interfacing with Cocoon). I don't think it's a big problem to write some basic infrastructure to provide this (extending FOUserAgent or writing some FOPEnvironment class). Avalon would provide that already, as would probably other frameworks (such as Hivemind). In the end it depends on how much we will want to write ourselves and not depend on other libraries. Given the recent events in Avalon-land (and around it), I don't have a problem with going our own way although it doesn't sound ideal to me. Batik has done the same. Just a few thoughts... On 30.04.2004 23:29:19 Stefan Seifert wrote: > > > What about interface javax.xml.transform.URIResolver with > > > > javax.xml.transform.Source resolve(String href, String base) ? > > > > Note that org.apache.xml.resolver.tools.CatalogResolver is an > > implementation of this interface using various sorts of catalogs. > > Well, i'm not sure if thats helping us here, because the different > resolving/source concepts seem primarly to target resolving one string > url into another string. My aim is to resolve a string source uri and > get an input stream (like it is done by excalibur source resolving or - > in a more simple way - by the > java.net.URL/URLStreamHandler/URLConnection connection classes used by > FOP 0.20.5 in the current implementation). Jeremias Maerki