My mistake - you're right on the getDynaProperties() implementation.
Maybe its not a bad idea, but then again there are easier methods - I uses
caches which use the "name" of the DyanClass. Another issue is it would work
for your "regular" DynaClass, but those that also implement the
MutableDynaClass (e.g. LazyDynaClass) would have problems since dyna
properties can be added/removed which would change the hash code.
Also since DynaClass is just an interface we could change the
implementations provided in BeanUtils but theres no way of guaranteeing that
custom implementations outside of BeanUtils would implement it in this
standard fashion.
Perhaps the best way would be to provide a generateHashCode(DynaClass)
method and compare DynaClasses method (and getDyanProperties() method) in
one of the utils beans to make it easier for people to implement these types
of behaviours - maybe a new DynaUtils would be a good idea for this?
If you think its worth it then submit a bugzilla ticket, preferably with
code :-)
Niall
P.S. toString() utility methods for DynaClass and DynaBean might make good
additons as well.
----- Original Message -----
From: "Kris Nuttycombe" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 06, 2004 8:40 PM
Subject: Re: [beanutils] PropertyUtils & DynaBeans
> Ah, I hadn't realized that WrapDynaClass cached automatically. That
> basically solves my problem with the
> PropertyUtils.get*PropertyDescriptors() methods not supporting DynaBeans.
>
> I still think it wouldn't be a bad idea for DynaClasses to implement
> hashCode() and equals() in a standard fasion.
>
> Kris
>
> As an aside, you probably mean this, right?
>
> public DynaProperty[] getDynaProperties(Object bean) {
> return (bean instanceof DynaBean)
> ? ((DynaBean)bean).getDynaClass().getDynaProperties()
> :
WrapDynaClass.createDynaClass(bean.getClass()).getDynaProperties();
> }
>
>
>
> Niall Pemberton wrote:
>
> >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" <[EMAIL PROTECTED]>
> >To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> >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" <[EMAIL PROTECTED]>
> >>>To: "Commons Developers Jakarta" <[EMAIL PROTECTED]>
> >>>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: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
> --
> =====================================================
> Kris Nuttycombe
> Associate Scientist
> Geospatial Data Services Group
> CIRES, National Geophysical Data Center/NOAA
> (303) 497-6337
> [EMAIL PROTECTED]
> =====================================================
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
