Re: [beanutils] PropertyUtils & DynaBeans

[Paulo Gaspar]

Hi Niall,
Obviously, I must apologise for previous remarks, since you are up to 
date with the DynaBean stuff implementation and I am completelly outdated.

But now I am curious: how does the whole introspection caching stuff  
work if there are multiple class loaders? Is there some provision to 
handle using classe loaded by multiple sibling classloaders or should 
its use be restricted to a "single classloader universe"?

With my best regards,
Paulo Gaspar
Niall Pemberton wrote:
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]