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
whatThe 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
canyour 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
beingget 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
PropertyUtils.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
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]
