Marcus,
This parameters object you are referring is read-only by semantics, but
not by syntax. It is used as an optimization, instead of writing:
> if (isSelected("userstatus", "permitted", listOfMaps,
> new Parameters(), objectModel)) {
sitemap uses static instance. The solution is to have unmodifiable
wrapper parameters class available, as it is done in java collections
library. Then, sitemap could be modified to use it:
> /** An empty <code>Parameter</code> used to pass to the sitemap
components
> */
> private Parameters emptyParam =
> Parameters.unmodifiableParameters(new Parameters());
Hope this is clear enough,
Regards,
Vadim
> -----Original Message-----
> From: Marcus Crafter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 20, 2001 12:42 PM
> To: Cocoon Developers Mailing List
> Subject: Sitemap parameters object & Threads
>
> 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).
>
> 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
>
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: ManageSoft GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&' Email : [EMAIL PROTECTED]
> &&&&. Business Hours : +49 69 9757 200
> &&&&&&&:
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
