struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cedric Dumoulin <>
Subject Re: Should this be called a bug ?
Date Sat, 22 Feb 2003 11:10:03 GMT

  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 
  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.

Pankaj Dhoolia wrote:

>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
>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?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message