You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Phillip Rhodes <rh...@yahoo.com> on 2001/12/21 23:23:30 UTC

torque generates overloaded methods-problem for reflection

I have been having troubles with my generated classes from torque and 
finally figured out what was wrong.

All the facts...using the TDK out the box, but get this, using the taglibs 
from struts.  The taglibs "bean" uses an object name and property name to 
look up the object in the specified scope and write out the property 
value.  It uses reflection for this.  However they did reflection, it won't 
work always for overloaded methods.  From my understanding it's a 
limitation of reflection vs. the struts implementation.  That's why I am here.

Here is from the java.sun.com reflection FAQ:
If a class has an overloaded method, does the Method.invoke() method use 
the types of the arguments to select which method will be invoked?
No. Method.invoke() is always invoked on a specific overloading of the 
method, previously selected by a call to Class.getMethod() or by other 
means. The Reflection API does not automatically choose between overloadings.


Reflection (introspection) will not work well if there is method 
overloading in a class.  In torque generated classes, there is 
overloading.    Has anyone had problems with this?  is there a work 
around?  I don't want to customize my torque generated classes!


Example...

     public void setScaleId(String v ) throws Exception
     {
          setScaleId(new NumberKey(v));
     }
      public void setScaleId(NumberKey v ) throws Exception
      {
         ....
         }

Thanks...  I will be able to contribute to others want I am up to speed 
with turbine.




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: torque generates overloaded methods-problem for reflection

Posted by John McNally <jm...@collab.net>.
Colin Chalmers wrote:
> 
> Hi John,
> 
> We noticed the problem you mention below (two setters first one found is
> used (not always correct one)) in the 2.2 src from a couple of weeks ago.
> Could you (pretty please?)  confirm your fix is in the latest 2.2 src? This
> would help resolve a workaround I had to implement for a colleague which
> meant having the method in question public whilst the others were protected
> (if I remember it correctly).
>

The changes are in cvs as of Oct 21.  Are you experiencing the same
behavior as before?  The code in PropertyDescriptor, that is being used
now, appears correct and I have been running with the fulcrum version
with no problems.  BeanInfo contained the bug and it is no longer being
used.

john mcnally

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: torque generates overloaded methods-problem for reflection

Posted by Colin Chalmers <co...@maxware.nl>.
Hi John,

We noticed the problem you mention below (two setters first one found is
used (not always correct one)) in the 2.2 src from a couple of weeks ago.
Could you (pretty please?)  confirm your fix is in the latest 2.2 src? This
would help resolve a workaround I had to implement for a colleague which
meant having the method in question public whilst the others were protected
(if I remember it correctly).

Thx

/Colin


> I have modified the version of intake in fulcrum so that it looks up the
> getter first.  It suffers from the limitation that there must always be
> a getter/setter pair, however.  This is not a problem for the torque
> generated objects as this is always true, but it is annoying to have to
> create a setter in other objects when it is not used.  I believe this
> fix should be in the 2.x tree as well.
>
> john mcnally
>
> Phillip Rhodes wrote:
> >
> > I have been having troubles with my generated classes from torque and
> > finally figured out what was wrong.
> >
> > All the facts...using the TDK out the box, but get this, using the
taglibs
> > from struts.  The taglibs "bean" uses an object name and property name
to
> > look up the object in the specified scope and write out the property
> > value.  It uses reflection for this.  However they did reflection, it
won't
> > work always for overloaded methods.  From my understanding it's a
> > limitation of reflection vs. the struts implementation.  That's why I am
here.
> >
> > Here is from the java.sun.com reflection FAQ:
> > If a class has an overloaded method, does the Method.invoke() method use
> > the types of the arguments to select which method will be invoked?
> > No. Method.invoke() is always invoked on a specific overloading of the
> > method, previously selected by a call to Class.getMethod() or by other
> > means. The Reflection API does not automatically choose between
overloadings.
> >
> > Reflection (introspection) will not work well if there is method
> > overloading in a class.  In torque generated classes, there is
> > overloading.    Has anyone had problems with this?  is there a work
> > around?  I don't want to customize my torque generated classes!
> >
> > Example...
> >
> >      public void setScaleId(String v ) throws Exception
> >      {
> >           setScaleId(new NumberKey(v));
> >      }
> >       public void setScaleId(NumberKey v ) throws Exception
> >       {
> >          ....
> >          }
> >
> > Thanks...  I will be able to contribute to others want I am up to speed
> > with turbine.
> >
> > _________________________________________________________
> >
> > Do You Yahoo!?
> >
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: torque generates overloaded methods-problem for reflection

Posted by John McNally <jm...@collab.net>.
Torque generates the following methods

public XKey getFoo()
public void setFoo(XKey key)
public void setFoo(String key)

The BeanIntrospector should look up the getter to determine the property
type and then use that to find the setter.  Note that there can only be
one getter, so it should not be a problem.  BeanIntrospector contains a
bug, however, and it looks up a setter first and takes whichever one it
finds first and then looks for a getter that matches.

I have modified the version of intake in fulcrum so that it looks up the
getter first.  It suffers from the limitation that there must always be
a getter/setter pair, however.  This is not a problem for the torque
generated objects as this is always true, but it is annoying to have to
create a setter in other objects when it is not used.  I believe this
fix should be in the 2.x tree as well.

john mcnally

Phillip Rhodes wrote:
> 
> I have been having troubles with my generated classes from torque and
> finally figured out what was wrong.
> 
> All the facts...using the TDK out the box, but get this, using the taglibs
> from struts.  The taglibs "bean" uses an object name and property name to
> look up the object in the specified scope and write out the property
> value.  It uses reflection for this.  However they did reflection, it won't
> work always for overloaded methods.  From my understanding it's a
> limitation of reflection vs. the struts implementation.  That's why I am here.
> 
> Here is from the java.sun.com reflection FAQ:
> If a class has an overloaded method, does the Method.invoke() method use
> the types of the arguments to select which method will be invoked?
> No. Method.invoke() is always invoked on a specific overloading of the
> method, previously selected by a call to Class.getMethod() or by other
> means. The Reflection API does not automatically choose between overloadings.
> 
> Reflection (introspection) will not work well if there is method
> overloading in a class.  In torque generated classes, there is
> overloading.    Has anyone had problems with this?  is there a work
> around?  I don't want to customize my torque generated classes!
> 
> Example...
> 
>      public void setScaleId(String v ) throws Exception
>      {
>           setScaleId(new NumberKey(v));
>      }
>       public void setScaleId(NumberKey v ) throws Exception
>       {
>          ....
>          }
> 
> Thanks...  I will be able to contribute to others want I am up to speed
> with turbine.
> 
> _________________________________________________________
> 
> Do You Yahoo!?
> 
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: torque generates overloaded methods-problem for reflection

Posted by Brian Lawler <bl...@branuity.com>.
I thought it was your getter's that were causing you trouble.  The get method for
the generated classes is not overloaded, but in your case (as in mine) the get 
method returns an object of a type that is not defined in java.lang.  Again, I 
don't know if this has any bearing on the problem, all I know is that when I 
temporarily changed the generated class to return a String instead of a StringKey
the getter was found.

The workaround that I am currently using is the following:

Method getGetter(String attr)
    throws Exception
{
    StringBuffer getter = new StringBuffer("get");
    getter.append(attr.substring(0, 1).toUpperCase()).
     append(attr.substring(1));
    return(org.apache.velocity.util.introspection.Introspector.getMethod(
     _beanClass, getter.toString(), EMPTY_ARGS));
}

It is kludgy and it should not be necessary, but I didn't have the time or 
motivation to dig into the introspection stuff to figure out the actual problem.

-Brian



Phillip Rhodes <rh...@yahoo.com> wrote:

> I have been having troubles with my generated classes from torque and 
> finally figured out what was wrong.
> 
> All the facts...using the TDK out the box, but get this, using the taglibs 
> from struts.  The taglibs "bean" uses an object name and property name to 
> look up the object in the specified scope and write out the property 
> value.  It uses reflection for this.  However they did reflection, it won't 
> work always for overloaded methods.  From my understanding it's a 
> limitation of reflection vs. the struts implementation.  That's why I am here.
> 
> Here is from the java.sun.com reflection FAQ:
> If a class has an overloaded method, does the Method.invoke() method use 
> the types of the arguments to select which method will be invoked?
> No. Method.invoke() is always invoked on a specific overloading of the 
> method, previously selected by a call to Class.getMethod() or by other 
> means. The Reflection API does not automatically choose between overloadings.
> 
> 
> Reflection (introspection) will not work well if there is method 
> overloading in a class.  In torque generated classes, there is 
> overloading.    Has anyone had problems with this?  is there a work 
> around?  I don't want to customize my torque generated classes!
> 
> 
> Example...
> 
>      public void setScaleId(String v ) throws Exception
>      {
>           setScaleId(new NumberKey(v));
>      }
>       public void setScaleId(NumberKey v ) throws Exception
>       {
>          ....
>          }
> 
> Thanks...  I will be able to contribute to others want I am up to speed 
> with turbine.
> 
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


-- 
Brian Lawler


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>