cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: JXTemplate is broken by implementing Recycable interface
Date Wed, 10 Oct 2007 12:21:40 GMT
On 10.10.2007 4:45 Uhr, Leszek Gawron wrote:

> 1. Can somebody tell me why do we need all these:
> 
> protected static final ContentHandler EMPTY_CONTENT_HANDLER = new 
> DefaultHandler();
> 
> /** The <code>XMLConsumer</code> receiving SAX events. */
> protected XMLConsumer xmlConsumer;
> 
> /** The <code>ContentHandler</code> receiving SAX events. */
> protected ContentHandler contentHandler = EMPTY_CONTENT_HANDLER;
> 
> /** The <code>LexicalHandler</code> receiving SAX events. */
> protected LexicalHandler lexicalHandler = 
> DefaultLexicalHandler.NULL_HANDLER;
> 
> in AbstractXMLProducer?
> 
> I might understand why the need for separate lexicalHandler and 
> contentHandler. Still why the need for the default value? Why aren't 
> they simply null?

I'd guess exactly for NOT being null and avoiding NPEs.

> /**
>  * Set the <code>XMLConsumer</code> that will receive XML data.
>  * <br>
>  * This method will simply call <code>setContentHandler(consumer)</code>
>  * and <code>setLexicalHandler(consumer)</code>.
>  */
> public void setConsumer(XMLConsumer consumer) {
>     this.xmlConsumer = consumer;
>     setContentHandler(consumer);
>     setLexicalHandler(consumer);
> }
> 
> It looks like we are fulfilling some really old dependencies here...

What's your point? Are you concerned that consumer is used 3-times? 
That's probably because some components don't want to have it set 
directly but implement the setters and wrap the consumer with some filter.

> 2. Look at SitemapModelComponent:

>>     void setup(SourceResolver resolver, Map objectModel, String src, 
>> Parameters par)     throws ProcessingException, SAXException, 
>> IOException;
>> }
> 
> It looks like we could drop the source resolver and objectModel. Both 
> can be injected and AFAIU both are properly scoped with some custom 
> scope of ours.

But that's an interface and the method is probably called by the 
pipeline. You still have to support both Avalon and Spring and need at 
least a migration path in the pipeline.

Joerg

Mime
View raw message