Hi Mehdi, that adapter is the beginning of that convenience adapter I was talking about. But there are a few issues with it (without having tried to run the code): - a StreamSource does not always have an InputStream. Apache XML Commons Resolver usually returns a StreamSource with just the resolved URL set as the system ID if I remember correctly. The URL has to be opened via java.net.URL. - SAXSource will also need to be handled aside from DOMSource. - a Source cannot be a StreamResult, so you can't use URIResolver for URLs that will be written to. URIResolver is strictly on the reading side. - TransformerExceptions should probably be re-thrown as IOException(WithCause) rather than RuntimeException.
At any rate, I'd like to point you to http://wiki.apache.org/xmlgraphics-fop/HowTo/XmlCommonsResolver which contains a working example for using XML catalogs with FOP. I believe that this is something that more than a handful of people are using in production so it would be great if this functionality remains available, even if it's just through that URIResolverAdapter. The performance loss with DOMSource/SAXSource, I can probably stomach, but I'm only speaking for myself. But I beg you not to replace URIResolver by ResourceResolver in the XGC Image Loading Framework. If your goal is to better control where files are written by FOP, that's one thing, or not wanting to deal with StreamSource's many accessors when just loading a font which always requires an InputStream, that's another. But URIResolver is just more powerful when it comes to provide read-access to resources that may be a byte stream, character stream, XML DOM, SAX event source like is the case with images. Thanks, Jeremias Maerki On 30.07.2012 13:02:41 mehdi houshmand wrote: > Jeremias, > > I was looking into this, and it became abundantly clear that I don't really > know what you're trying to do with the java.xml.transform.URIResolver... > Would something like this be appropriate as an adapter between the two > interfaces? (The exception handling is pretty slap-dash). I don't have a > great deal of experience with these XML libraries other than the fairly > basic use-cases. > > I appreciate that the DOMSource serialization would be performance costly, > but we already knew that... > > Mehdi > > On 30 July 2012 08:52, mehdi houshmand <med1...@gmail.com> wrote: > > > Hi Jeremias, > > > > I'm sorry for the slow response, I will look at this when I get the chance > > to do so and get back to you. I would like to come to some sort of > > compromise on this, one where we're both happy with the acquisition of > > resources. Failing that, at least come to an agreement where neither of us > > are particularly happy but begrudgingly accept with a healthy amount of > > resentment ;) > > > > Mehdi > > > > > > On 26 July 2012 22:31, Jeremias Maerki <d...@jeremias-maerki.ch> wrote: > > > >> (responded on fop-dev) > >> > >> > >> Jeremias Maerki > >> > >> > >> On 26.07.2012 20:17:17 mehdi houshmand wrote: > >> > I appreciate that there are inconveniences, but if you're just looking > >> for > >> > backwards compatibility, the changes should be, for the most part, > >> fairly > >> > minor. > >> > > >> > I'm sorry we haven't been able to convince you of the benefits of the > >> > changes, that's on me as the lead on this. I'm not sure really what > >> else I > >> > can do to convince you, if you have specific concerns that we could > >> address > >> > then I'd be happy to see if we can come to some sort of compromise. You > >> > talk about a java.xml.transform.URIResolver interface, are there any > >> other > >> > things you'd like to see? > >> > > >> > On 26 July 2012 17:15, Jeremias Maerki <d...@jeremias-maerki.ch> wrote: > >> > > >> > > That's not quite true. That worked perfectly before by setting your > >> own > >> > > JAXP URIResolver. You could even resolve a URI to a DOMSource (or > >> > > SAXSource) containing an SVG image that you've dynamically built based > >> > > on some data (think charts). With the new approach, you have to > >> > > serialize that XML to a stream (buffered in memory or on disk) which > >> > > costs performance. Not a very common use case, I know, but we're > >> talking > >> > > possibilities that are going away with the API changes. > >> > > > >> > > Previously, you could use Apache XML Commons Resolver for XML catalog > >> > > functionality. Now you probably have to write an adapter from > >> > > URIResolver to ResourceResolver (haven't had time to try that, yet). A > >> > > convenience adapter is missing. > >> > > > >> > > > >> > > Jeremias Maerki > >> > > > >> > > > >> > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote: > >> > > <snip/> > >> > > > Btw... it's really nice that all data is loaded now through the new > >> URI > >> > > > resolver. In the near future I'd like to use a custom scheme (e.g. > >> > > > myscheme://imageid) in order to load images instead of using HTTP. > >> That > >> > > > wouldn't be possible without your change. So thanks! > >> > > <snip/> > >> > > > >> > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > >> > > For additional commands, e-mail: > >> fop-users-h...@xmlgraphics.apache.org > >> > > > >> > > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > >> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > >> > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
