David Graham wrote:
If not synchronizing is the only reason for freezing the config, then we
may want to reconsider that decision. Is there really a noticable
performance improvement by not synchronizing?
It makes sense that the config objects are frozen because then they
reflect exactly what's in the config file. OTOH, it may be useful to
dynamically change the config. Maybe a configuration setting to not
freeze the config objects?
Dave
If your change needs to be reflected in the underlying FooConfig objects
and collections, you're going to have a problem -- after the freeze()
method is called, any call to a property setter on these things will
throw
IllegalStateException. The reason for this is so that Struts can access
the HashMaps used for internal storage without needing to synchronize,
since it knows that the undelrying map cannot be changed by another
thread.
Craig
I do not want to change the configuration for all time.
I alway want to suggest at initialisation that object class B should
be used instead A and do that programmatically.
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
