Carsten Ziegeler wrote:
> 
> > Stefano Mazzocchi wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > This is actually I feature I am looking for since weeks, but had never
> > > time to finish it....
> > >
> > > There is of course the ThreadSafe interface from Avalon, but then
> > > you have only one single instance in the whole system. That's not
> > > suitable for many cases.
> > >
> > > I would like to add a Cocoon-specific marker interface, similar
> > > to the SitemapModelComponent  interface (but a different name)
> > > >>>
> > > public interface RequestModelComponent extends Component {
> > >     /**
> > >      * Set the <code>SourceResolver</code>, objectModel
> > <code>Map</code>,
> > >      * the source and sitemap <code>Parameters</code> used to
> > process the
> > > request.
> > >      */
> > >     void setup(SourceResolver resolver, Map objectModel) throws
> > > ProcessingException;
> > > }
> > > <<<<
> > >
> > > The behaviour for this would be:
> > > - The first time during a request processing a component marked with
> > >   this interface is looked up, a new instance is created (or got from
> > >   the pool) and the setup method is called. This object is stored
> > >   somewhere so that the ComponentManager has access to it for later
> > >   requests.
> > > - The second, third.. time during the same request this component is
> > >   looked up, it is get from the store and the setup() method is
> > >   not looked up
> > > - Every time a release is called on this object, nothing really happens
> > > - When the request processing is finished, the ComponentManager
> > >   must really release all stored objects.
> > >
> > > So actually objects marked in this way are more or less ThreadSafe
> > > but per request exists a different instance.
> >
> > Hmmm, not sure I understand the need for such a behavior. I mean: if you
> > don't call setup() in subsequent requests, wouldn't you get into an
> > inconsistent state for the environment variables?
> >
> > Can you make an example of use, I'm probably missing your point.
> >
> We use this behaviour for many utility components. Although this is not
> a "real world example" and might not be appropriate modelled, lets imagine
> a component for statistics. In order to work correctly this component needs
> access to the objectModel (to get the request object and from that the
> current requestURI) and it "logs" how many components are used during the
> processing of one request.
> Imagine a simple pipeline with a generator, transformer and serializer.
> The generator looksup the "Statistics" component called SCA, it is created
> from scratch
> (or taken from a pool) and the setup() method is called.
> The generator now sends his information to SCA. Now the transformer
> looks up a "Statistics" component to send his information. If now a new
> instance SCB would be created, this instance would not know about the
> information
> previously send to SCA, so we need the same instance SCA here.
> As this instance is already setup there is no need to call this method
> again.
> 
> If in the same time a different request is processed parallel which uses
> the same pipeline (or any other, it doesn't really matter), the generator
> looks up its own "Statistics" component, which of course can not be SCA as
> it
> is used in the other pipeline.
> It is a "new" instance which is used exclusivly in this pipeline.
> 
> So summarizing it:
> - a ThreadSafe component is shared by all components  in all requests.
> - a "normal" component is not shared at all, each component gets its own
> instance.
> - a RequestModelComponent is shared by all components in the *same* request.
> 
> I think this is a pattern which is very useful in building xml applications
> with Cocoon 2.

Ok, gotcha.

+1 from me.
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<[EMAIL PROTECTED]>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to