Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of craigmcc@gmail.com designates
 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=GgP2O4l9P3m4hzBrNjunqwvyAyL6U/pzVUdd52maU2xW+VlfsFHjnoHbJ/vpd/L5mxd4SreKBF5nInTOD6o+qJjYk8rclHZoigU2BaGY82OND4TmexU1/Cbi1wngJkd+3EuLJo0YZXXqQpj7enPcyMWc+8XRtp7+775NSk4rqWA=
Message-ID: <f8b39ace0611230102v742699fcyaddaeb496788ec44@mail.gmail.com>
Date: Thu, 23 Nov 2006 01:02:32 -0800
From: "Craig McClanahan" <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [BeanUtils] Why does needs the method declaring a class to be
 public
In-Reply-To: <31cc37360611230016m676b016ft4f5f3b66403d4b86@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_104423_5583292.1164272552370"
References: <4564388A.3030704@bestsolution.at>
	 <4565502C.1000003@bestsolution.at>
	 <31cc37360611230016m676b016ft4f5f3b66403d4b86@mail.gmail.com>

------=_Part_104423_5583292.1164272552370
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 11/23/06, Henri Yandell <flamefew@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

------=_Part_104423_5583292.1164272552370--