This is a known behavior ;-).
It is not a bug, it is an implementation choice (for efficiency, this reduce the number of objects created ).
In the normal usage, you should only consult, add or remove attributes from ComponentContext. You should not modify the attributes obtained from the ComponentContext !
A componentContext is created for each inserted tile. This componentContext is populated from the corresponding definition: the attributes are initialized. Instead of creating a new value for each attribute, we reference the value stored in the definition. If you get it and modify it, the modification will be reflected by all subsequent calls.
An attribute value can be any kind of object, even a user defined one. So, it is hard to enforce a read-only API on the attribute value. The only solution is to copy the attribute value each time we use it. This will lead to several object creations. More than 99.9% of the application doesn't need to modify the attributes. So, I don't want to let them pay the price for the 0.01% remaining. These remaining applications can do the attribute copy themselves when needed ;-).
An improvement can be done by changing the current attribute definition objects and let them disallow modifications. This can be an improvement request in bugzilla.
Cedric
Pankaj Dhoolia wrote:
Hi,
Current implementation of ComponentContext is such that you can make
changes to it in such a manner that the base definition cached with the
DefinitionFactory will reflect those changes. In effect it is possible
to cause global changes for all subsequent requests thru the
ComponentContext API. Was this intended or is it a bug, because for the
List type attributes ComponentContext lands up having a reference point
right in the definition cached in the DefinitionFactory?
cheers, pdhoolia
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
