cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: [WARNING] Re: cvs commit: xml-cocoon/src/org/apache/cocoon/generation
Date Thu, 10 May 2001 06:00:38 GMT
Sorry wasn't finished when my mailer send the mail,
so here again the whole message (Strange what happens
if you accidentally press escape...)

> Berin Loritsch wrote:
> wrote:
> > 
> > cziegeler    01/05/09 08:25:22
> > 
> >   Modified:    src/org/apache/cocoon/generation Tag: xml-cocoon2
> >               
>   Log:
> >   Made HTMLGenerator cacheable
> >   -public class HTMLGenerator extends ComposerGenerator 
> implements Poolable {
> >   +public class HTMLGenerator extends ComposerGenerator 
> implements Cacheable {
> Do not confuse the difference between a Component that is 
> Poolable and one that is Cacheable!
> Sitemap Components are NOT Threadsafe, so they must either be 
> Poolable or SingleThreaded.
> Avalon Excalibur's Component Management Framework (which Cocoon 
> incidently uses), defaults
> to SingleThreaded (or FACTORY based creation) handling of 
> objects, in effect becoming
> SingleThreaded.  That means that for every request, a new 
> HTMLGenerator is created--instead
> of using a previously created one.
> Cacheing is the process of checking if the requested resource (or 
> file) has been changed,
> and if not using the cached version.
> If you remove the Poolable interface from HTMLGenerator, in 
> essence you are saying
> that you want to instantiate, set the Logger, configure, setup 
> the sitemap component,
> perform cache checks, generate, and decommission the 
> HTMLGenerator for EACH request.
> By pooling, we only setup the sitemap component, perform cache 
> checks, and generate
> for each request.
Yes, I really know the difference between Poolable and Cacheable.
BUT most components (e.g. all Generators, Transformers and Serializers)
extends the AbstractXMLProducer which is Recyclable!!!! 
So there is no need for all these components to declare the
Poolable interface by itself. 
I removed it as I found it very confusing to extend a base class
which is Recyclable and declare myself again(!) Poolable. If I do
that I it is very easy to forget to implement the recycle() method
in the subclass.

So personally I am +2 to remove the "implements Poolable" from
the classes again. What do you think?


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto: 

To unsubscribe, e-mail:
For additional commands, email:

View raw message