You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2002/10/31 23:29:06 UTC
[lang] MethodUtils [WAS Re: [beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils]
On Sunday, October 27, 2002, at 09:42 PM, Stephen Colebourne wrote:
<snip>
> Robert, as you have probably spotted, I have created a number of new
> classes
> and a new API for the reflect subpackage in [lang]. FieldUtils is about
> finished, but MethodUtils is modtly commented out.
>
> So, there is still much work todo before beanutils can actually depend on
> lang. But if you can help thats great.
hi Stephen
i haven't read anything bad about my proposal so i plan to start work on
this stuff soon.
i've taken a quick look and you've made quite a few changes. any pointers
you'd like to give me about these changes?
i've noticed that you've commented out the invokeMethod implementation. my
first job will be to get that working about. are there any modifications
that you need me to make to the commented out code (or is it just a case
of get it working again)?
one of the consequences of MethodUtils being in lang is that lang can't
depend on commons-logging. i found that without logging, it's nearly
impossible to debug some things.
what i'd like to do is add a debug boolean and a log method (probably both
private) that logs messages to System.out. this would allow debugging
calls to remain in place *but* we'd have to remember to switch the flag
back off before committing. is that ok with you?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, November 2, 2002, at 01:41 PM, Stephen Colebourne wrote:
<snip>
>> my main issue with the current MethodUtils API is that it not precise in
>> it's definition of expected behaviour. the API does not say 'this methods
>> finds conforms to the JLS spec'. since these methods can be called
>> directly (rather than just as part of beanutils or digester where the
>> required behaviour is clear), this lack precision means that people may
>> rely on these features. therefore changing the algorithm might break
>> their
>> code.
>
> The comments in [lang] MethodUtils etc. should be tightened. We offer the
> equivalent of:
> getMethod() accessible
> getDeclaredMethod() accessible
> getMethod() ignoring scope
> getDeclaredMethod() ignoring scope
>
> The first two should follow the JLS spec. The last two we get to define
> what
> happens.
sounds good to me. we'd need to think clearly on the definition of those
ignoring scope and get that fixed before we release. but, there's no
reason why we'd need to wait until those were finished before releasing
implementations for those following the JLS rules.
since we're most likely going to end up with a series of methods, any
ideas about naming conventions?
one alternative to actually including them all in the same class might be
split into two classes (possibly sharing common code). we might have
PublicMethodUtils for those following the JLS rules and another class for
those with looser scope (i can't think of a good name for that class right
now).
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> i don't want to support two implementations. i want to create a correct
> implementation in lang that can be used by beanutils and digester. then i
> can deprecate the MethodUtils in beanutils and leave it to rot.
+1
> my main issue with the current MethodUtils API is that it not precise in
> it's definition of expected behaviour. the API does not say 'this methods
> finds conforms to the JLS spec'. since these methods can be called
> directly (rather than just as part of beanutils or digester where the
> required behaviour is clear), this lack precision means that people may
> rely on these features. therefore changing the algorithm might break their
> code.
The comments in [lang] MethodUtils etc. should be tightened. We offer the
equivalent of:
getMethod() accessible
getDeclaredMethod() accessible
getMethod() ignoring scope
getDeclaredMethod() ignoring scope
The first two should follow the JLS spec. The last two we get to define what
happens.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, November 2, 2002, at 10:34 AM, Stephen Colebourne wrote:
<snip>
> Of course the net result of the above is that the lang version might work
> differently from the beanutils one if the beanutils one doesn't follow the
> JLS. I reckon thats a beanutils issue to solve ;-)
i don't want to support two implementations. i want to create a correct
implementation in lang that can be used by beanutils and digester. then i
can deprecate the MethodUtils in beanutils and leave it to rot.
the big problem is with class.getMethod(). this is very badly broken (in
many JVM's) and does not conform to the JLS (compiler) spec. beanutils and
other components require reflection that conforms to the JLS spec rather
than whatever reflection rules various JVM happen to have.
MethodUtil's was factored out from other classes to contain code to cope
with the bug reports we kept getting from people whose introspection
failed. i think that the algorithm now finds most methods but might find
too many.
my main issue with the current MethodUtils API is that it not precise in
it's definition of expected behaviour. the API does not say 'this methods
finds conforms to the JLS spec'. since these methods can be called
directly (rather than just as part of beanutils or digester where the
required behaviour is clear), this lack precision means that people may
rely on these features. therefore changing the algorithm might break their
code.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I agree, with Craig's position. So far I have looked only at the FieldUtils.
What I found was that 1.3 reflection was badly broken, and 1.4 still had a
few oddities. The problem lay with the getField() method. getDecleredField()
was fine.
Thus the only way I can see to replicate hard coded method references is to
write the JLS algorithms ourselves. This is what I tried to do in
FieldUtils. However I must point out that I didn't re-read the JLS, or write
tests. I just worked empirically. So please don't rely on FieldUtils at this
stage!
(I put the classes in lang proper not because they were finished, but to
gain more eyeballs and effort ;-)
In addition to the main lookup as a hard coded reference would, I added the
ability to find the 'first match' irrespective of scope, using the
setAccessible() method to gain access. This is a specific boolean flag
choice to use however, so its additional power not less or a default.
Of course the net result of the above is that the lang version might work
differently from the beanutils one if the beanutils one doesn't follow the
JLS. I reckon thats a beanutils issue to solve ;-)
Stephen
PS. Note that the main problem I had was where a private field in a
superclass should hide a public field in a super-super-class but didn't (in
1.3 reflection).
> On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
> > If the *default* method resolution for picking the correct method is
> > different from the default resolution that the Java compiler does for
> > figuring out which method to call for hard-coded method references, I
> > would suggest that that the resolution algorithm is totally broken and
> > should be rejected out of hand. There is no reason to expect users of
> > [lang] to expect anything different from this.
> >
> > It doesn't matter any more if it makes sense or not -- this is the Java
> > world as it really exists. Deal with it, or plan on being ignored.
> >
> > If the available non-default algorithms work on some more "sane" or
> > "rational" algorithms (from our point of view as library developers),
that
> > is fine -- as long as the user has to *deliberatey* choose to be
different
> > from what the normal expectations would be.
> > On Fri, 1 Nov 2002, robert burrell donkin wrote:
> some good points strongly made. i think that's helped to clarify some
> things for me.
>
> i'm not sure that the lang API should end up with a default method - just
> a range of clearly defined ones. components using the library should pick
> the one which is most appropriate.
>
> from a beanutils and digester perspective, i wouldn't give users the
> choice - i'd say that compiler equivalence is definitely what's needed. so
> those components should use the compiler equivalent methods in the API.
>
> one major problem with the current MethodUtil's implementation is that it'
> s aims are fuzzy. the aim should have been to find methods exactly as the
> compiler does. in practice, i suspect that the workarounds for the bugs in
> reflection implementations may mean that some methods which shouldn't be
> found, are found. we've also got some methods in there that allow users to
> rely on the reflection ideosyncracies of whatever JVM they're currently
> running on. this (with hindsight) was probably a poor idea.
>
> so i'd like a cleaner and clearer API.
>
> if beanutils finds either more or less methods than the compiler would,
> then IMHO both cases are equally buggy. but this isn't clear in the
> current API. the current situation allows users quite reasonably to rely
> on behaviour that should IMHO be buggy (ie replying on beanutils to find
> methods which wouldn't be found by the compiler).
>
>
> how does this sound to everyone?
>
> - robert
>
>
> --
> 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: [lang] MethodUtils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
> On Fri, 1 Nov 2002, robert burrell donkin wrote:
<snip>
>> but that sounds like the right way to write the API. one of the
>> weaknesses
>> of MethodUtil's is that the API grew rather than being designed.
>
> I have a very strong piece of advice for the [lang] developers (which,
> among other things, will be translated into a -1 on any attempt to convert
> [beanutils] to depend on a [lang] implementation that doesn't correspond
> to the expectations outlined below).
>
> If the *default* method resolution for picking the correct method is
> different from the default resolution that the Java compiler does for
> figuring out which method to call for hard-coded method references, I
> would suggest that that the resolution algorithm is totally broken and
> should be rejected out of hand. There is no reason to expect users of
> [lang] to expect anything different from this.
>
> It doesn't matter any more if it makes sense or not -- this is the Java
> world as it really exists. Deal with it, or plan on being ignored.
>
> If the available non-default algorithms work on some more "sane" or
> "rational" algorithms (from our point of view as library developers), that
> is fine -- as long as the user has to *deliberatey* choose to be different
> from what the normal expectations would be.
some good points strongly made. i think that's helped to clarify some
things for me.
i'm not sure that the lang API should end up with a default method - just
a range of clearly defined ones. components using the library should pick
the one which is most appropriate.
from a beanutils and digester perspective, i wouldn't give users the
choice - i'd say that compiler equivalence is definitely what's needed. so
those components should use the compiler equivalent methods in the API.
one major problem with the current MethodUtil's implementation is that it'
s aims are fuzzy. the aim should have been to find methods exactly as the
compiler does. in practice, i suspect that the workarounds for the bugs in
reflection implementations may mean that some methods which shouldn't be
found, are found. we've also got some methods in there that allow users to
rely on the reflection ideosyncracies of whatever JVM they're currently
running on. this (with hindsight) was probably a poor idea.
so i'd like a cleaner and clearer API.
if beanutils finds either more or less methods than the compiler would,
then IMHO both cases are equally buggy. but this isn't clear in the
current API. the current situation allows users quite reasonably to rely
on behaviour that should IMHO be buggy (ie replying on beanutils to find
methods which wouldn't be found by the compiler).
how does this sound to everyone?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 1 Nov 2002, robert burrell donkin wrote:
> Date: Fri, 1 Nov 2002 18:36:42 +0000
> From: robert burrell donkin <ro...@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [lang] MethodUtils
>
>
> On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
>
> > From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> >> i've taken a quick look and you've made quite a few changes. any pointers
> >> you'd like to give me about these changes?
> >
> > I wanted to ensure that the API allowed a choice between the four options
> > I
> > could find:
> > Match on specified class only vs Match on class and superclasses
> > Match on public methods/fields vs Match on any field made accessible via
> > setAccessible
>
> (presumably, 'Match on class and superclasses' includes superinterfaces)
>
> but that sounds like the right way to write the API. one of the weaknesses
> of MethodUtil's is that the API grew rather than being designed.
>
I have a very strong piece of advice for the [lang] developers (which,
among other things, will be translated into a -1 on any attempt to convert
[beanutils] to depend on a [lang] implementation that doesn't correspond
to the expectations outlined below).
If the *default* method resolution for picking the correct method is
different from the default resolution that the Java compiler does for
figuring out which method to call for hard-coded method references, I
would suggest that that the resolution algorithm is totally broken and
should be rejected out of hand. There is no reason to expect users of
[lang] to expect anything different from this.
It doesn't matter any more if it makes sense or not -- this is the Java
world as it really exists. Deal with it, or plan on being ignored.
If the available non-default algorithms work on some more "sane" or
"rational" algorithms (from our point of view as library developers), that
is fine -- as long as the user has to *deliberatey* choose to be different
from what the normal expectations would be.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
>> i've taken a quick look and you've made quite a few changes. any pointers
>> you'd like to give me about these changes?
>
> I wanted to ensure that the API allowed a choice between the four options
> I
> could find:
> Match on specified class only vs Match on class and superclasses
> Match on public methods/fields vs Match on any field made accessible via
> setAccessible
(presumably, 'Match on class and superclasses' includes superinterfaces)
but that sounds like the right way to write the API. one of the weaknesses
of MethodUtil's is that the API grew rather than being designed.
> The biggest problem is with the public methods/fields version, because
> Java
> reflection in 1.3 Sun gives the wrong answers to getField() and getMethod(
> )
> in certain circumstances. (See previous threads - reflection how accurate)
yep. MethodUtils really grew as result of this problem.
(but i didn't know that (all of?) these problems were fixed in java 1.4)
>> i've noticed that you've commented out the invokeMethod implementation.
>> my
>> first job will be to get that working about. are there any modifications
>> that you need me to make to the commented out code (or is it just a case
>> of get it working again)?
>
> I was going to see if that commented out code did the same thing for
> Methods
> that I had coded for Fields.
the major aim of the code was to address the problems with finding methods
by name which you pointed out above. maybe i'll take a look and see how it
compares with yours.
the algorithm is currently slow and should be rewritten to make it more
efficient.
what i'd like to do first, though, is just switch the old one back on and
copy the test cases from beanutils into lang. that should insure that we
don't lose functionality if the algorithm is changed or replaced.
if most of the problems solved by MethodUtils are fixed in java 1.4, then
it's important to keep testing on older JVMs. (i'm running 1.3 at the
moment so that shouldn't be a big problem.)
>> one of the consequences of MethodUtils being in lang is that lang can't
>> depend on commons-logging. i found that without logging, it's nearly
>> impossible to debug some things.
>>
>> what i'd like to do is add a debug boolean and a log method (probably
>> both
>> private) that logs messages to System.out. this would allow debugging
>> calls to remain in place *but* we'd have to remember to switch the flag
>> back off before committing. is that ok with you?
>
> I am -1 for [lang] to depend on [logging], thus this is the best solution.
> System.err might be better however.
ok, i'll make it System.err.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
<snip>
>> i've noticed that you've commented out the invokeMethod implementation.
>> my
>> first job will be to get that working about. are there any modifications
>> that you need me to make to the commented out code (or is it just a case
>> of get it working again)?
>
> I was going to see if that commented out code did the same thing for
> Methods
> that I had coded for Fields.
basically the stuff you commented out is the code that's been developed in
beanutils to fix the bugs in the getMethod implementation. it's this stuff
which is particularly useful for people running on JVM's with buggy
implementations.
my plan is to uncomment the code and copy all the MethodUtils test cases
into lang. i think that it should be easier to create a good version in
lang (containing all the workarounds developed in beanutils) if we
establish a reference version containing working versions of the old
methods before we start tinkering.
i'll then try to move the test cases along to the replacement methods once
we decide what they are.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][logging] dependencies (was: Re: [lang] MethodUtils)
Posted by Costin Manolache <cm...@yahoo.com>.
Michael Davey wrote:
> Henri Yandell wrote:
>
>> I'm +1 for System.err too. Should this be institutionalised across Lang?
>
> There has been discussion before about a 'Core' component with the bare
> minimum from various commons components and upon which (nearly) every
> commons component would depend.
>
> Could the Log interface, LogFactory, SimpleLog and NoOpLog classes be
> moved to 'Core' leaving the rest in Logging (thus making Logging an
> extension to Core's
> logging functionality)? The only obvious Core candidates from Lang (for
> me) are Nestable*.
>
I don't see any reason for [logging] to depend on [lang], so
it is perfectly fine if lang uses logging.
It is possible that some drivers will use [lang] - for example
to use Nestable to provide this feature for log4j - but that
shouldn't be part of commons-logging, but part of a special
commons-logging-log4j.jar.
In general I think it was a bad idea to mix the drivers in
the same interface with the API ( I'm waiting the "I told you so" :-).
I think the ant pattern ( ant-foo.jar for the drivers that are dependent
of "foo" ) is a very good one.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang][logging] dependencies (was: Re: [lang] MethodUtils)
Posted by Michael Davey <Mi...@CodeRage.ORG>.
Henri Yandell wrote:
> I'm +1 for System.err too. Should this be institutionalised across Lang?
There has been discussion before about a 'Core' component with the bare minimum
from various commons components and upon which (nearly) every commons component
would depend.
Could the Log interface, LogFactory, SimpleLog and NoOpLog classes be moved to
'Core' leaving the rest in Logging (thus making Logging an extension to Core's
logging functionality)? The only obvious Core candidates from Lang (for me) are
Nestable*.
--
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils [WAS Re: [beanutils][lang][PROPOSAL] deprecated
beanutils version of MethodUtils]
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 1 Nov 2002, Stephen Colebourne wrote:
> > what i'd like to do is add a debug boolean and a log method (probably both
> > private) that logs messages to System.out. this would allow debugging
> > calls to remain in place *but* we'd have to remember to switch the flag
> > back off before committing. is that ok with you?
>
> I am -1 for [lang] to depend on [logging], thus this is the best solution.
> System.err might be better however.
Unless some genius comes up with a nice solution to cyclic dependencys,
I'm +1 for System.err too. Should this be institutionalised across Lang?
[Must draw up a dependency tree for Commons, unless reactor or gump
generate one already]
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons/lang STATUS.html
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
lang committers:
veto now - or forever hold your peace,
for tomorrow will be too late.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is lang mavenized?
Posted by Henri Yandell <ba...@generationjava.com>.
Yeah, it's a by hand one so you have to remember to add the test case to
it if necessary [well, the suite anyway].
That gets me everytime :)
On Thu, 7 Nov 2002, robert burrell donkin wrote:
> On Thursday, November 7, 2002, at 07:05 PM, Henri Yandell wrote:
>
> > The ant build, though the maven one should be fine. Usually around a
> > release I post a version of the maven site for Lang on a personal server
> > so we can benefit from the reports etc.
>
> cool.
>
> (i'm working on test cases so i wanted to check before messing with a
> mavenized build.xml.)
>
> - robert
>
> > Hen
> >
> > On Thu, 7 Nov 2002, robert burrell donkin wrote:
> >
> >> is the maven build or the ant build generally recognized by langineers as
> >> the reference way to build?
> >>
> >> - robert
> >>
> >>
> >> --
> >> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> >> org>
> >> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> >> org>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> > org>
> > For additional commands, e-mail: <mailto:commons-dev-help@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: [lang] is lang mavenized?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, November 7, 2002, at 07:05 PM, Henri Yandell wrote:
> The ant build, though the maven one should be fine. Usually around a
> release I post a version of the maven site for Lang on a personal server
> so we can benefit from the reports etc.
cool.
(i'm working on test cases so i wanted to check before messing with a
mavenized build.xml.)
- robert
> Hen
>
> On Thu, 7 Nov 2002, robert burrell donkin wrote:
>
>> is the maven build or the ant build generally recognized by langineers as
>> the reference way to build?
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
>> org>
>> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
>> org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang] MethodUtil getMatchingAccessibleMethod
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i think that the MethodUtils version that stephen's been working on in
reflect is an older version which doesn't contain some bugs fixes. i'm
going to replace (what i think is) the older getMatchingAccessibleMethod()
code with the bug fixed version.
i'm not going to commit anything just yet, so would people please shout
out if they see any possible problems with this.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is lang mavenized?
Posted by Henri Yandell <ba...@generationjava.com>.
The ant build, though the maven one should be fine. Usually around a
release I post a version of the maven site for Lang on a personal server
so we can benefit from the reports etc.
Hen
On Thu, 7 Nov 2002, robert burrell donkin wrote:
> is the maven build or the ant build generally recognized by langineers as
> the reference way to build?
>
> - robert
>
>
> --
> 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>
[lang] is lang mavenized?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
is the maven build or the ant build generally recognized by langineers as
the reference way to build?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils [WAS Re: [beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> i've taken a quick look and you've made quite a few changes. any pointers
> you'd like to give me about these changes?
I wanted to ensure that the API allowed a choice between the four options I
could find:
Match on specified class only vs Match on class and superclasses
Match on public methods/fields vs Match on any field made accessible via
setAccessible
The biggest problem is with the public methods/fields version, because Java
reflection in 1.3 Sun gives the wrong answers to getField() and getMethod()
in certain circumstances. (See previous threads - reflection how accurate)
> i've noticed that you've commented out the invokeMethod implementation. my
> first job will be to get that working about. are there any modifications
> that you need me to make to the commented out code (or is it just a case
> of get it working again)?
I was going to see if that commented out code did the same thing for Methods
that I had coded for Fields.
> one of the consequences of MethodUtils being in lang is that lang can't
> depend on commons-logging. i found that without logging, it's nearly
> impossible to debug some things.
>
> what i'd like to do is add a debug boolean and a log method (probably both
> private) that logs messages to System.out. this would allow debugging
> calls to remain in place *but* we'd have to remember to switch the flag
> back off before committing. is that ok with you?
I am -1 for [lang] to depend on [logging], thus this is the best solution.
System.err might be better however.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] MethodUtils [WAS Re: [beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils]
Posted by Steve Downey <st...@netfolio.com>.
On Thursday 31 October 2002 05:29 pm, robert burrell donkin wrote:
> On Sunday, October 27, 2002, at 09:42 PM, Stephen Colebourne wrote:
>
> <snip>
>
> > Robert, as you have probably spotted, I have created a number of new
> > classes
> > and a new API for the reflect subpackage in [lang]. FieldUtils is about
> > finished, but MethodUtils is modtly commented out.
> >
> > So, there is still much work todo before beanutils can actually depend on
> > lang. But if you can help thats great.
>
> hi Stephen
>
> i haven't read anything bad about my proposal so i plan to start work on
> this stuff soon.
>
> i've taken a quick look and you've made quite a few changes. any pointers
> you'd like to give me about these changes?
>
> i've noticed that you've commented out the invokeMethod implementation. my
> first job will be to get that working about. are there any modifications
> that you need me to make to the commented out code (or is it just a case
> of get it working again)?
>
> one of the consequences of MethodUtils being in lang is that lang can't
> depend on commons-logging. i found that without logging, it's nearly
> impossible to debug some things.
>
> what i'd like to do is add a debug boolean and a log method (probably both
> private) that logs messages to System.out. this would allow debugging
> calls to remain in place *but* we'd have to remember to switch the flag
> back off before committing. is that ok with you?
>
System.err, instead of System.out? And how about something like
static {
if (System.getProperty("org.apache.commons.lang.Debug") != null) {
debugLogging = true;
}
}
If it's useful for us, it might be useful for other developers.
> - robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [land] Land/Logging WAS: [lang] MethodUtils
Posted by Steve Downey <st...@netfolio.com>.
I think the API/implementation split for logging is the right way to handle
it. As long as the API doesn't depend on [lang], and I don't see a reason it
really should, the problem is fairly straightforward. Bootstraping the build
will mean building logging-api, then lang, then the rest of logging.
A bit messy, but not irretrievably so.
On Thursday 31 October 2002 10:04 pm, Henri Yandell wrote:
> On Thu, 31 Oct 2002, robert burrell donkin wrote:
> > one of the consequences of MethodUtils being in lang is that lang can't
> > depend on commons-logging. i found that without logging, it's nearly
> > impossible to debug some things.
>
> As a hypothetical, what are the bad sides to Lang being dependent on
> Logging. It would obviously be nice to have a Lang which logs output.
>
> I would hope that the JDK someday would have good internal logging
> support.
>
> However, Logging also might want to depend on Lang. So we have the classic
> cyclic dependency. Solutions? Merge?
>
> Anyways. I'm not proposing this, I just want to generate some thoughts..
>
> Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[land] Land/Logging WAS: [lang] MethodUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 31 Oct 2002, robert burrell donkin wrote:
> one of the consequences of MethodUtils being in lang is that lang can't
> depend on commons-logging. i found that without logging, it's nearly
> impossible to debug some things.
As a hypothetical, what are the bad sides to Lang being dependent on
Logging. It would obviously be nice to have a Lang which logs output.
I would hope that the JDK someday would have good internal logging
support.
However, Logging also might want to depend on Lang. So we have the classic
cyclic dependency. Solutions? Merge?
Anyways. I'm not proposing this, I just want to generate some thoughts..
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>