commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@blueyonder.co.uk>
Subject Re: [beanutils] PropertyUtils & DynaBeans
Date Mon, 06 Dec 2004 19:16:00 GMT
OK the performance issue is a good point, but I don't agree with your
reasoning to include it in PropertyUtils.

WrapDynaClass instances are singletons as it already caches instances of
itself - (it's constructor is private and new WrapDynaClass intances are
created with the static createDynaClass() method which uses a cache).

So I guess your proposed getDynaProperties(Object bean) method would look
something like

public DynaProperty[] getDynaProperties(Object bean)  {
    return (bean instanceof DynaBean)
            ? ((DynaBean)bean).getDynaClass().getDynaProperties()
            : WrapDynaBean.createDynaClass(bean).getDynaProperties();
}

...with no need to cache anything in PropertyUtils. Maybe this is a nice
convenience method, but I'm pretty neutral about whether it should be added
to the API or not.


Niall


----- Original Message ----- 
From: "Kris Nuttycombe" <Kris.Nuttycombe@noaa.gov>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, December 06, 2004 5:31 PM
Subject: Re: [beanutils] PropertyUtils & DynaBeans


> The main issue is that my code needs to perform bean introspection on an
> Object without knowing whether that object is a regular bean or a
> DynaBean. Sure, I could add a clause like you suggest everywhere I want
> to do this, but it seems like this is really something that should be
> handled in PropertyUtils so that introspection information can be
> cached. The system I'm working on processes tens of thousands of objects
> at a pass, so creating a new WrapDynaBean for each object when a lookup
> on the classlass would suffice seems excessive.
>
> Kris
>
>
>
> Niall Pemberton wrote:
>
> >Maybe you could spell out the issues with PropertyUtils and DynaBeans and
> >the methods involved and what you're trying to do because its not clear
what
> >your trying to resolve.
> >
> >I'm don't see much value in the getDynaProperties() method being in
> >PropertyUtils - all you need to do is make eveything a DynaBean then you
can
> >get the DynaProperties and do whatever you want using the existing
> >DynaBean/DynaClass methods -  no need for PropertyUtils at all.
> >
> >DynaBean dynaBean = (bean instanceof DynaBean)
> >            ? (DynaBean)bean : new WrapDynaBean(bean);
> >
> >For caching to work people are going to have to change how they create
> >DynaBeans and I believe its better left up to the environment they're
being
> >used in to implement a caching mechanism - Struts does this for its
> >DynaActionForm implementation.
> >
> >Niall
> >
> >----- Original Message ----- 
> >From: "Kris Nuttycombe" <Kris.Nuttycombe@noaa.gov>
> >To: "Commons Developers Jakarta" <commons-dev@jakarta.apache.org>
> >Sent: Saturday, December 04, 2004 12:55 AM
> >Subject: [beanutils] PropertyUtils & DynaBeans
> >
> >
> >
> >
> >>Hi, all,
> >>
> >>As it currently stands, PropertyUtils doesn't support DynaBeans for a
> >>number of its methods. It doesn't make much sense to return
> >>PropertyDescriptors for DynaBeans, but it's no great pain to use
> >>WrapDynaClass on an ordinary class and thereby be able to introspect
> >>either regular beans or DynaBeans using the same interface. To support
> >>this, I'd like to add a method with the signature:
> >>
> >>DynaProperty[] getDynaProperties(Object bean)
> >>
> >>to PropertyUtilsBean, with a corresponding static method in
PropertyUtils.
> >>
> >>Now, one of the other advantages of using PropertyUtilsBean is that it
> >>caches the introspected data. Conceivably, this would also be a useful
> >>feature for the getDynaProperties method. However, here we have a
> >>problem: since DynaClass doesn't have any way to enforce that its
> >>implementations implement HashCode, there's no way to use the same map
> >>caching strategy as is used for the PropertyDescriptors. This
> >>illustrates a larger issue, which is that DynaClass objects aren't
> >>singletons like Class objects are.
> >>
> >>To resolve this, I propose adding an AbstractDynaClass base class that
> >>implements hashCode() and equals() based upon the public methods
> >>available in DynaClass. This way, even if DynaClasses aren't singletons,
> >>they can be used for hash keys. It might be also useful to implement a
> >>registry for DynaClasses in this abstract class to provide
> >>singleton-like functionality. Existing DynaClass implementations would
> >>be modified to extend AbstractDynaClass.
> >>
> >>Any thoughts?
> >>
> >>Kris



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