Hi Joerg,
Joerg Heinicke schrieb:
On 22.11.2007 6:04 Uhr, Andreas Hartmann wrote:
I used an action to pass the current source resolver to the
SourceProtocolHandler, but this resulted in an NPE because the URI of
the TranscoderInput object was null. After I applied a little patch to
the SourceProtocolHandler which enabled the fallback to the default
handler if the URL to resolve is null, it worked.
I tried shortly to get into it. I found some SourceProtocolHandler code
disabled (in comments) in SVGSerializer.
it looks like you disabled this code:
27277 joerg //SourceProtocolHandler.setup(this.resolver);
r27277 | joerg | 2004-02-07 14:18:16 +0100 (Sat, 07 Feb 2004) | 2 lines
revert the setting of the Cocoon source resolver for batik as this
breaks internal URIs and so our batik and ascii art samples
Can you tell me how the mentioned objects interact with eachother?
The SourceProtocolHandler registers itself at the ParsedURL class in a
static block. Apparently the SVGSerializer passed the SourceResolver of
the current thread to the SourceProtocolHandler to enable it to resolve
the custom protocols of the Cocoon application. Maybe you disabled it
because you experienced the same problem that I reported?
Your solution sounds more like a workaround.
IMO that depends on the question if
ParsedURLProtocolHandler.parseURL(String) is supposed to expect null
parameters. I asked on the Batik users list.
The SVGSerializer doesn't set the URI of the TranscoderInput object:
<snip src="SVGSerializer:203">
TranscoderInput transInput = new TranscoderInput(doc);
// Buffering is done by the pipeline (See shouldSetContentLength)
TranscoderOutput transOutput = new TranscoderOutput(this.output);
transcoder.transcode(transInput, transOutput);
</snip>
Maybe the problem can be prevented if transInput.setURI(String) is
called before, but I have no idea which URI string to pass.
Is the SourceProtocolHandler supposed to work out of the box?
Is it possible that I did something wrong which lead to the NPE?
Is there a recommended way to setup the SourceProtocolHandler?
I can not answer these questions :) I only know that Batik once suffered
from the same problems as FOP, it was not possible to resolve URLs with
Cocoon's source resolver. For FOP it had architectural reasons which are
fixed in 0.9.x branch. I wonder if anybody has ever investigated it so
deeply for Batik or if it was just fixed in the meantime.
I had some trouble making the Batik block work with Batik 1.7 Beta 1
(one exception fix lead to the next until I gave up). Maybe I'll get a
helpful reply from the Batik community.
Thanks a lot for your comments!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
