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]
