Giacomo Pati wrote:
>
> On Thu, 20 Dec 2001, Marcus Crafter wrote:
>
> > Hi All,
> >
> > Hope all is well.
> >
> > On avalon-dev there's been a short discussion about the
> > Parameters object that is used in the generated sitemap
> > class. I thought I'd bring it up here so we can flesh out a
> > solution.
> >
> > Have a look at this snippet from a generated sitemap:
> >
> > ----------------------
> > public class sitemap_xmap extends AbstractSitemap {
> > static final String LOCATION = "org.apache.cocoon.www.sitemap_xmap";
> >
> > static {
> > dateCreated = 1007984808622L;
> > }
> >
> > /** An empty <code>Parameter</code> used to pass to the
> sitemap components */
> > private Parameters emptyParam = new Parameters();
> >
> > <snip>...
> >
> > if (isSelected("userstatus", "permitted", listOfMaps,
> > emptyParam, objectModel)) {
> > ----------------------
> >
> > The problem is 2 fold, and has to do with the 'emptyParam'
> > reference when it's passed into the invocation of selectors and
> > actions, etc:
> >
> > 1. The Parameters class itself is not thread safe. Concurrent
> > updates to the one object may corrupt data.
> >
> > 2. There is only one parameter object across the whole sitemap,
> > accessed by all threads, and potentially many pipelines.
> >
> > The second point is the killer if a developer decides to set a
> > parameter in a selector, or action, etc, and read it back elsewhere.
> > The problem is that the one object is shared among all
> threads - if 2
> > threads update the object (regardless of whether it's threadsafe
> > or not), results can be undefined if they use the same key.
> >
> > As far as I can see there's no real need to be able to set
> > parameters in this object in selectors and actions, etc, as
> the Request
> > object can handle sharing of data between pipeline components via
> > set/getAttribute (or is there some other use for it ?).
> >
> > If this is the case, we could make the parameters object read-only
> > before it's passed to selectors, etc, which would prevent
> this problem
> > from occuring (for example by wrapping it, or toggling its
> > read-only flag).
>
> If we can vote +1 here I can commit an already patched sitemap.xsl which
> makes the emptyParam read-only.
>
Hey, you beat me by 15 minutes. Hmpf, next time, I'll be faster.
Ok, keeping it short: +1 to commit the patch.
Carsten
> Giacomo
>
> >
> > Alternatively, we could change the generated sitemap code to
> > create a new Parameters object per thread. I'm not sure how much
> > this influences other uses of this object though. Perhaps
> > someone else a bit closer to that part of the code might be able to
> > comment better ?
> >
> > I'm wondering what everyone else's thoughts are on a solution
> > for this as it seems 'emptyParam' is used almost everywhere in
> > the generated sitemap class, and could be a touchy thing to
> > change.
> >
> > Any comments/thoughts ?
> >
> > Cheers,
> >
> > Marcus
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
