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 >> >> >
URIResolverAdapter.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
