commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [beanutils] beans for static utility classes
Date Wed, 30 Apr 2003 12:55:41 GMT

On Tuesday, February 25, 2003, at 11:21 PM, Craig R. McClanahan wrote:

>
>
> On Tue, 25 Feb 2003, robert burrell donkin wrote:
>
>> Date: Tue, 25 Feb 2003 22:45:16 +0000
>> From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
>> Reply-To: Jakarta Commons Developers List <commons-
>> dev@jakarta.apache.org>
>> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>> Subject: [beanutils] beans for static utility classes
>>
>> beanutils has a fair number of utility classes which are composed of
>> static methods. i'd like to create proper beans containing the
>> implementation code and have the static methods call an instance.
>>
>> this would allow users to create different instances with - for example 
>> -
>> different registered convertors. see
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14848
>>
>> and
>>
>> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=104613177905644&w=
>> 2
>>
>> it would also allow normal inheritance to be used to improve the 
>> structure
>> of the code allowing - for example - the easier maintenance of the locale
>> beanutils code:
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16038
>>
>> it would also allow improved and more flexible caching to be developer to
>> improve performance. see:
>>
>> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103929482023502&w=
>> 2
>>
>> comments?
>>
>> anyone objections to me implementing these changes?
>>
>
> +1.
>
> We should, however, create a factory method (perhaps based on
> commons-discovery technology) to create an appropriate implementation of
> the proper beans for you.  That way, we could support pluggable
> replacements for the standard implementation classes quite easily.
>
> Finally, the factory should be configurable to (or default to) creating an
> instance per class loader.  That way, for example, the cache of
> introspected beans that PropertyUtils maintains for one webapp won't
> conflict with the cache for a different webapp, even if commons-beanutils
> is loaded from a parent class loader.

i've been looking into this. i am right in thinking that it's the context 
classloader of the thread making the call which should be used to match 
the instance, aren't i?

(otherwise, i don't understand quite what you meant.)

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message