Re: Should this be called a bug ?

[Cedric Dumoulin <ce...@apache.org>]

  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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org