commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [beanutils] statics
Date Sat, 07 Dec 2002 21:00:11 GMT

On Saturday, December 7, 2002, at 05:11 PM, Craig R. McClanahan wrote:

> On Sat, 7 Dec 2002, robert burrell donkin wrote:
>> Date: Sat, 7 Dec 2002 09:10:47 +0000
>> From: robert burrell donkin <>
>> Reply-To: Jakarta Commons Developers List <commons-
>> To: Jakarta Commons Developers List <>
>> Subject: [beanutils] statics [WAS Re: [digester] collections and default
>>     for useThreadClassLoader]
>> On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote:
>> <snip>
>>> There is also the issue of statics ( which become very visible when
>>> you move stuff to the top loader), and the issue of security - which is
>>> particularily important for beanutil and probably in collections
>>> ( i.e. - if things are cached - can an application access other
>>> application's data ? Is there any thread that may change the
>>> security context ? )
>> (now is probably a good time to raise something that's been in the air 
>> for
>> a little while.)
>> at the moment, beanutils is composed of static methods. the caching is
>> also static.
>> one effect of this is that there is only one global set of converters.
>> another is that the cached data has to be shared globally.
>> it might make more sense to have concrete objects. caches and other data
>> would be stored with each instance. the current static methods would then
>> call a static instance.
>> users would then be free to continue to use the convenient static methods
>> or they could create an instance and use that instead.
> +1 on exploring this, with appropriate factory methods and such.  It might
> also be interesting to support a mode that maintains a "static"-ish cache
> per context class loader via the existing call signatures, because that's
> a very useful scenario in things like a servlet container.

that sounds good.

the classes in beanutils depend on each other. ao we'll need to make sure 
that the instances are linked consistently together. probably the 
delegated instances should be exposed as read-only properties.

a single per context class loader cache for the whole of beanutils (rather 
than per class) seems like a good idea. that way, we can easily make sure 
that a consistent set of all beanutils objects will be created every time.

- robert

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

View raw message