> 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.
Carsten
> > I didn't look much more in the Avalon code, but I thought, implementing
> > an own ComponentManager which does exactly this behaviour in the
> > lookup and release methods would be simply enough.
>
> Yes, in case we need cocoon-specific behavior, extending avalon's
> component manager is the way to go, rather than forcing new behaviors up
> into avalong foodchain.
>
> --
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
