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.
First and formost I must stress that unless you are using only one method
in a Component, you cannot guarantee it to be threadsafe. (i.e. setUp then
getModel).
Secondly, trying to make setUp() only called on the first invocation of the
Component is not consistent with intended use. The ResourceManager and
objectModel can be different for each request. Especially the objectModel.
You cannot assume they will stay the same for the life of the Component.
Lastly, from the time you look up a Component to the time you release it,
its state is guaranteed to be the same. After you release it, it follows
the rules of the CM.
> > 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.
Keep in mind, a better understanding of Avalon code will keep you from
reinventing the wheel--poorly. Avalon's code has been tested and hammered,
and I would be resistent to new functionality if you can use what exists
currently. There are some specific ComponentSelectors in Cocoon, but they
extend Avalon's ComponentSelector, and add specific functionality.
I don't quite get what you are driving at that you think Avalon doesn't
support. (Who knows, there might be a good reason for it).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
