cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hartmann <andr...@apache.org>
Subject Re: Enabling the SourceProtocolHandler in the Batik block
Date Mon, 26 Nov 2007 12:15:02 GMT
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


Mime
View raw message