You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tom Schindl <li...@bestsolution.at> on 2006/11/22 12:46:18 UTC
[BeanUtils] Why does needs the method declaring a class to be public
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
------------8<------------
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
------------8<------------
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
------------8<------------
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
------------8<------------
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
------------8<------------
if( ! Modifier.isPrivate(clazz.getModifiers()) && !
Modifier.isPackage(clazz.getModifiers()) ) {
}
------------8<------------
PropertyUtilsBean#invokeMethod(...):
------------8<------------
method.setAccessible(true);
return method.invoke(bean,values);
------------8<------------
I first wanted to discuss this here and not creating an bug immediately.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Tom Schindl <li...@bestsolution.at>.
Hi,
Craig McClanahan schrieb:
> On 11/23/06, Henri Yandell <fl...@gmail.com> wrote:
[...]
> If BeanUtils is going to continue to evolve on the trajectory that seems to
> be epitomized by recent comments on the mailing list and in JIRA issues, it
> will need to be modified to deal with scenarios like this. On the other
> hand, more modern approaches to both configuration management (alternative
> strategies for parsing configuration files plus completely different
> approaches like JAXB), plus the decoupling of modern web frameworks from
> hard coded things like a Struts ActionForm, means that my personal need to
> care about what happens in BeanUtils is pretty much zero. I don't consider
> it an appropriate place to do innovative development, but if you are
> interested in improving support for legacy applications then it is (of
> course) fertile ground for incremental improvements -- some of which could
> be pretty substantial improvements in usabilty.
>
Well for me BeanUtils are a really usable components because the classes
I need to deal with in my framework are not 100% JavaBeans (they are
SWT-Widgets I'm loading from XML-Spec to design GUIs in a language
called XSWT) so other technologies to instantiate them fail for me
miserably and BeanUtils really help me here a lot to set the various
values with nearly no custom code.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be public
Posted by Craig McClanahan <cr...@apache.org>.
On 11/23/06, Henri Yandell <fl...@gmail.com> wrote:
>
> JIRA reports are good - we've a big backlog in BeanUtils but it's
> starting to go down.
>
> There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
>
> I don't know why the API is designed to only work with public methods;
> whether that's an aspect of adherence to the spec, by design or
> legacy. Seems that if we're going to use setAccessible, that we could
> just open it to package and private too.
>
> Anyone know why MethodUtils intentionally limits itself?
There is indeed a large dose of "legacy" here ... the early versions of
BeanUtils (which came out of Struts in the pre-1.0 days) were never
consciously designed to be a general purpose bean property manipulation
library (i.e. the "BeanUtils" moniker was something of a stretch :-). The
sole initial intents were to provide for the type conversions that Digester
needed, plus the "copy request parameters to a form bean" that the
1.xversion of a Struts ActionForm needed. Hence, there was never any
initial
consideration for supporting the more esoteric cases that a general purpose
framework would need to support.
If BeanUtils is going to continue to evolve on the trajectory that seems to
be epitomized by recent comments on the mailing list and in JIRA issues, it
will need to be modified to deal with scenarios like this. On the other
hand, more modern approaches to both configuration management (alternative
strategies for parsing configuration files plus completely different
approaches like JAXB), plus the decoupling of modern web frameworks from
hard coded things like a Struts ActionForm, means that my personal need to
care about what happens in BeanUtils is pretty much zero. I don't consider
it an appropriate place to do innovative development, but if you are
interested in improving support for legacy applications then it is (of
course) fertile ground for incremental improvements -- some of which could
be pretty substantial improvements in usabilty.
Have at it ... but you'll find me watching from the sidelines.
Hen
Craig McClanahan
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Tom Schindl <li...@bestsolution.at>.
Thanks Henri,
maybe we could make this configurable somehow. I can't read somewhere in
the spec of JavaBeans that you can't use inheritance.
Tom
Henri Yandell schrieb:
> JIRA reports are good - we've a big backlog in BeanUtils but it's
> starting to go down.
>
> There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
>
> I don't know why the API is designed to only work with public methods;
> whether that's an aspect of adherence to the spec, by design or
> legacy. Seems that if we're going to use setAccessible, that we could
> just open it to package and private too.
>
> Anyone know why MethodUtils intentionally limits itself?
>
> Hen
>
> On 11/22/06, Tom Schindl <li...@bestsolution.at> wrote:
>> Hi,
>>
>> Nobody any comments should I file a bug report against JIRA?
>>
>> Tom
>>
>> Tom Schindl schrieb:
>> > Hi,
>> >
>> > I have an issue the current implementation of
>> >
>> > MethodUtils#getAccessibleMethod(Method) where it reads:
>> >
>> > ------------8<------------
>> > if( Modifier.isPublic(clazz.getModifiers()) ) {
>> >
>> > }
>> >
>> > // Check the implemented interfaces and subinterfaces
>> > ------------8<------------
>> >
>> > With this check setting attributes on a class Hierarchy like the one
>> > below doesn't work:
>> >
>> > ------------8<------------
>> > class HiddenBean {
>> > private String a;
>> >
>> > protected HiddenBean() {
>> >
>> > }
>> >
>> > public void setA(String a) {
>> > this.a = a;
>> > }
>> >
>> > public String getA() {
>> > return this.a;
>> > }
>> > }
>> >
>> > public class PublicBean extends HiddenBean {
>> >
>> > }
>> > ------------8<------------
>> >
>> > The problem is that big framework like e.g. Eclipse often use
>> > package-visible classes to not expose too much API to the user and you
>> > can't use BeanUtils currently to set values.
>> >
>> > I came across this problem when trying to provide an enhanced
>> version of
>> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
>> because
>> > of this.
>> >
>> > What would be the problem to change the check to the following:
>> >
>> > MethodUtils#getAccessibleMethod(Method):
>> > ------------8<------------
>> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
>> > Modifier.isPackage(clazz.getModifiers()) ) {
>> >
>> > }
>> > ------------8<------------
>> >
>> > PropertyUtilsBean#invokeMethod(...):
>> > ------------8<------------
>> > method.setAccessible(true);
>> > return method.invoke(bean,values);
>> > ------------8<------------
>> >
>> > I first wanted to discuss this here and not creating an bug
>> immediately.
>> >
>> > Tom
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Tom Schindl <li...@bestsolution.at>.
Craig McClanahan schrieb:
> On 11/23/06, Tom Schindl <li...@bestsolution.at> wrote:
>>
>> Hi,
>>
>> the problem are not the methods visibility the methods in the sub-class
>> are public but their class declaration is not and you can call them if
>> you method.setAccessible(true) I've currently modified BeanUtils in my
>> project and it works perfectly.
>
>
> This solution will work (by default) ... until you try it on a server where
> a security manager with rational policies is enabled by default (such as
> had
> *better* be the case, for example, in a server environment that shares a
> JVM
> across multiple third party webapps). If you don't think this is imprtant,
> you might as well be coding in a scripting language, because you are giving
> up one of the key advantages of using a strongly typed language like Java.
you are right in server environments this might bring us into trouble
under certain circumstance.
That's why I proposed to make this configurable because e.g. in my case
stand-alone SWT-Application (Loading GUI from XML) doesn't have any
problems with it.
BTW what I can not really understand is why I can not call a *public*
method from a class without setAccessible(true) using reflection when I
can do it in any ordinary java application.
Providing access to private, package, protected scoped methods should
not be allowed by the way using BeanUtils. The only thing I request is
to call public methods!
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be public
Posted by Craig McClanahan <cr...@apache.org>.
On 11/23/06, Tom Schindl <li...@bestsolution.at> wrote:
>
> Hi,
>
> the problem are not the methods visibility the methods in the sub-class
> are public but their class declaration is not and you can call them if
> you method.setAccessible(true) I've currently modified BeanUtils in my
> project and it works perfectly.
This solution will work (by default) ... until you try it on a server where
a security manager with rational policies is enabled by default (such as had
*better* be the case, for example, in a server environment that shares a JVM
across multiple third party webapps). If you don't think this is imprtant,
you might as well be coding in a scripting language, because you are giving
up one of the key advantages of using a strongly typed language like Java.
Note that I am not at all dissing the choice to use such a language ... but
you should be aware of what you give up to gain the corresponding benefits.
Therefore I would be pretty unhappy with a proposal to make BeanUtils to
this sort of thing by default, without some deliberate choice by the
application developer (thereby explicitly accepting the security
vulnerabilities that come with setAccessbile() working as described here).
Tom
Craig
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Tom Schindl <li...@bestsolution.at>.
Hi,
the problem are not the methods visibility the methods in the sub-class
are public but their class declaration is not and you can call them if
you method.setAccessible(true) I've currently modified BeanUtils in my
project and it works perfectly.
Tom
Will Pugh schrieb:
> Since, MethodUtils is not going to be in the same package as whatever
> class you are calling a method on, I don't think you going to be allowed
> to call a package, protected or private methods in that class?
>
> --Will
>
> Henri Yandell wrote:
>> JIRA reports are good - we've a big backlog in BeanUtils but it's
>> starting to go down.
>>
>> There are a couple of other similar issues (BEANUTILS-157 +
>> BEANUTILS-87).
>>
>> I don't know why the API is designed to only work with public methods;
>> whether that's an aspect of adherence to the spec, by design or
>> legacy. Seems that if we're going to use setAccessible, that we could
>> just open it to package and private too.
>>
>> Anyone know why MethodUtils intentionally limits itself?
>>
>> Hen
>>
>> On 11/22/06, Tom Schindl <li...@bestsolution.at> wrote:
>>> Hi,
>>>
>>> Nobody any comments should I file a bug report against JIRA?
>>>
>>> Tom
>>>
>>> Tom Schindl schrieb:
>>> > Hi,
>>> >
>>> > I have an issue the current implementation of
>>> >
>>> > MethodUtils#getAccessibleMethod(Method) where it reads:
>>> >
>>> > ------------8<------------
>>> > if( Modifier.isPublic(clazz.getModifiers()) ) {
>>> >
>>> > }
>>> >
>>> > // Check the implemented interfaces and subinterfaces
>>> > ------------8<------------
>>> >
>>> > With this check setting attributes on a class Hierarchy like the one
>>> > below doesn't work:
>>> >
>>> > ------------8<------------
>>> > class HiddenBean {
>>> > private String a;
>>> >
>>> > protected HiddenBean() {
>>> >
>>> > }
>>> >
>>> > public void setA(String a) {
>>> > this.a = a;
>>> > }
>>> >
>>> > public String getA() {
>>> > return this.a;
>>> > }
>>> > }
>>> >
>>> > public class PublicBean extends HiddenBean {
>>> >
>>> > }
>>> > ------------8<------------
>>> >
>>> > The problem is that big framework like e.g. Eclipse often use
>>> > package-visible classes to not expose too much API to the user and you
>>> > can't use BeanUtils currently to set values.
>>> >
>>> > I came across this problem when trying to provide an enhanced
>>> version of
>>> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
>>> because
>>> > of this.
>>> >
>>> > What would be the problem to change the check to the following:
>>> >
>>> > MethodUtils#getAccessibleMethod(Method):
>>> > ------------8<------------
>>> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
>>> > Modifier.isPackage(clazz.getModifiers()) ) {
>>> >
>>> > }
>>> > ------------8<------------
>>> >
>>> > PropertyUtilsBean#invokeMethod(...):
>>> > ------------8<------------
>>> > method.setAccessible(true);
>>> > return method.invoke(bean,values);
>>> > ------------8<------------
>>> >
>>> > I first wanted to discuss this here and not creating an bug
>>> immediately.
>>> >
>>> > Tom
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Will Pugh <wi...@sourcelabs.com>.
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
> JIRA reports are good - we've a big backlog in BeanUtils but it's
> starting to go down.
>
> There are a couple of other similar issues (BEANUTILS-157 +
> BEANUTILS-87).
>
> I don't know why the API is designed to only work with public methods;
> whether that's an aspect of adherence to the spec, by design or
> legacy. Seems that if we're going to use setAccessible, that we could
> just open it to package and private too.
>
> Anyone know why MethodUtils intentionally limits itself?
>
> Hen
>
> On 11/22/06, Tom Schindl <li...@bestsolution.at> wrote:
>> Hi,
>>
>> Nobody any comments should I file a bug report against JIRA?
>>
>> Tom
>>
>> Tom Schindl schrieb:
>> > Hi,
>> >
>> > I have an issue the current implementation of
>> >
>> > MethodUtils#getAccessibleMethod(Method) where it reads:
>> >
>> > ------------8<------------
>> > if( Modifier.isPublic(clazz.getModifiers()) ) {
>> >
>> > }
>> >
>> > // Check the implemented interfaces and subinterfaces
>> > ------------8<------------
>> >
>> > With this check setting attributes on a class Hierarchy like the one
>> > below doesn't work:
>> >
>> > ------------8<------------
>> > class HiddenBean {
>> > private String a;
>> >
>> > protected HiddenBean() {
>> >
>> > }
>> >
>> > public void setA(String a) {
>> > this.a = a;
>> > }
>> >
>> > public String getA() {
>> > return this.a;
>> > }
>> > }
>> >
>> > public class PublicBean extends HiddenBean {
>> >
>> > }
>> > ------------8<------------
>> >
>> > The problem is that big framework like e.g. Eclipse often use
>> > package-visible classes to not expose too much API to the user and you
>> > can't use BeanUtils currently to set values.
>> >
>> > I came across this problem when trying to provide an enhanced
>> version of
>> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
>> because
>> > of this.
>> >
>> > What would be the problem to change the check to the following:
>> >
>> > MethodUtils#getAccessibleMethod(Method):
>> > ------------8<------------
>> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
>> > Modifier.isPackage(clazz.getModifiers()) ) {
>> >
>> > }
>> > ------------8<------------
>> >
>> > PropertyUtilsBean#invokeMethod(...):
>> > ------------8<------------
>> > method.setAccessible(true);
>> > return method.invoke(bean,values);
>> > ------------8<------------
>> >
>> > I first wanted to discuss this here and not creating an bug
>> immediately.
>> >
>> > Tom
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be public
Posted by Henri Yandell <fl...@gmail.com>.
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl <li...@bestsolution.at> wrote:
> Hi,
>
> Nobody any comments should I file a bug report against JIRA?
>
> Tom
>
> Tom Schindl schrieb:
> > Hi,
> >
> > I have an issue the current implementation of
> >
> > MethodUtils#getAccessibleMethod(Method) where it reads:
> >
> > ------------8<------------
> > if( Modifier.isPublic(clazz.getModifiers()) ) {
> >
> > }
> >
> > // Check the implemented interfaces and subinterfaces
> > ------------8<------------
> >
> > With this check setting attributes on a class Hierarchy like the one
> > below doesn't work:
> >
> > ------------8<------------
> > class HiddenBean {
> > private String a;
> >
> > protected HiddenBean() {
> >
> > }
> >
> > public void setA(String a) {
> > this.a = a;
> > }
> >
> > public String getA() {
> > return this.a;
> > }
> > }
> >
> > public class PublicBean extends HiddenBean {
> >
> > }
> > ------------8<------------
> >
> > The problem is that big framework like e.g. Eclipse often use
> > package-visible classes to not expose too much API to the user and you
> > can't use BeanUtils currently to set values.
> >
> > I came across this problem when trying to provide an enhanced version of
> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
> > of this.
> >
> > What would be the problem to change the check to the following:
> >
> > MethodUtils#getAccessibleMethod(Method):
> > ------------8<------------
> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
> > Modifier.isPackage(clazz.getModifiers()) ) {
> >
> > }
> > ------------8<------------
> >
> > PropertyUtilsBean#invokeMethod(...):
> > ------------8<------------
> > method.setAccessible(true);
> > return method.invoke(bean,values);
> > ------------8<------------
> >
> > I first wanted to discuss this here and not creating an bug immediately.
> >
> > Tom
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Why does needs the method declaring a class to be
public
Posted by Tom Schindl <li...@bestsolution.at>.
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
> Hi,
>
> I have an issue the current implementation of
>
> MethodUtils#getAccessibleMethod(Method) where it reads:
>
> ------------8<------------
> if( Modifier.isPublic(clazz.getModifiers()) ) {
>
> }
>
> // Check the implemented interfaces and subinterfaces
> ------------8<------------
>
> With this check setting attributes on a class Hierarchy like the one
> below doesn't work:
>
> ------------8<------------
> class HiddenBean {
> private String a;
>
> protected HiddenBean() {
>
> }
>
> public void setA(String a) {
> this.a = a;
> }
>
> public String getA() {
> return this.a;
> }
> }
>
> public class PublicBean extends HiddenBean {
>
> }
> ------------8<------------
>
> The problem is that big framework like e.g. Eclipse often use
> package-visible classes to not expose too much API to the user and you
> can't use BeanUtils currently to set values.
>
> I came across this problem when trying to provide an enhanced version of
> XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
> of this.
>
> What would be the problem to change the check to the following:
>
> MethodUtils#getAccessibleMethod(Method):
> ------------8<------------
> if( ! Modifier.isPrivate(clazz.getModifiers()) && !
> Modifier.isPackage(clazz.getModifiers()) ) {
>
> }
> ------------8<------------
>
> PropertyUtilsBean#invokeMethod(...):
> ------------8<------------
> method.setAccessible(true);
> return method.invoke(bean,values);
> ------------8<------------
>
> I first wanted to discuss this here and not creating an bug immediately.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org