commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [beanutils] beans for static utility classes
Date Wed, 30 Apr 2003 15:14:50 GMT

It will be more simple and I think it will work better if you will implement
stuff without singletons as "normal" instances and
static methods in beanutils can use this kind of objects internaly as
singletons without wokarounds.


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


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