ParsedURL and Virtuals Filesystems

Robert Marcano <[email protected]>
Newsgroups gmane.text.xml.batik.user
Message-ID <[email protected]>
Greetings.

I have been using Batik for a few years and I love its extensibility. I 
even use the CSS Engine directly for a non SVG dialect document without 
needing to add another library.

My problem right now is that I need to run/paint the SVG file inside 
some kind of virtual filesystem. The linked files inside the SVG 
(xml-stylesheet processing instructions, images...) are not on a real 
filesystem, they are on RAM isolated from any other SVG loaded. I tried 
using ParsedURL to define a new protocol but despite the advantages of 
it over the standard URL class, It still has the problem that protocol 
handlers are global, I haven't found a way to isolate a protocol for 
only a SVG document (I set the ParsedURL on the document directly 
because there is no real URL for it). I tried using ThreadLocal to 
create a ParsedURL protocol handler context aware, but I found many 
problems with this approach, Batik is not single threaded, some external 
to the svg resources are loaded with parsing, some of them are loaded on 
threads created by Batik out of my control (script on the document that 
add elements linking to external resources), so there is no easy way to 
use a ThreadLocal for that.

It would be nice if Batik could be extended with a VFS layer in order to 
be able work with svg files that resides on things not directly mapped 
to a virtual protocol, but that is something that I could hack a little 
later, in the short them I need to solve this problem with something 
less intrusive in the Batik codebase. Any help is really appreciated.

Note: I thought about registering those virtual files on some kind of 
global registry and then create a protocol handler accessing that 
registry but I am trying to avoid anything with globals because I need 
very good isolation between docs.

Thanks in advance
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.