On Saturday 19 October 2002 04:40 am, robert burrell donkin wrote: > hi steve > > interesting and useful comments. > > improved caching is something that i want to look at once this release is > out of the way, so i think that probably the best thing to do would be to > go without testing (of this fix) for this release. >
If the other tests pass, then it's at least correct to the first order. And the patch appears to be correct. > if you'll hang around, maybe we can all try to work out some good > strategies for cache testing and maybe open out this topic to other > components which are likely to have similar needs (eg. collections, lang, > reflection). > I'm not planning on going anywhere. > - robert > > On Friday, October 18, 2002, at 11:33 PM, Steve Downey wrote: > > If an API can't be tested, I tend to think there is something wrong with > > it. > > I've occasionally resorted to using protected deprecated methods to > > create a > > 'Testable' version of a class. Our practice is to have the tests in a > > different package than the classes being tested, so package scope doesn't > > help. > > > > Another tack, for aspects like cacheing, which really need to be > > invisible, is > > to add instrumentation. Either some way of quering cache stats, or > > registering a callback or event handler for cache misses. > > > > In practice, I like to be able to monitor the performance of a cache. The > > cache strategy might need to be changed, or the cache dumped entirely, if > > the > > cache just adds overhead. The application shouldn't care about caching, > > but > > the management of the app might. > > > > On Friday 18 October 2002 03:01 pm, Craig R. McClanahan wrote: > >> On Fri, 18 Oct 2002, robert burrell donkin wrote: > >>> Date: Fri, 18 Oct 2002 19:47:07 +0100 > >>> From: robert burrell donkin <[EMAIL PROTECTED]> > >>> Reply-To: Jakarta Commons Developers List > >>> <[EMAIL PROTECTED]> To: Jakarta Commons Developers List > >>> <[EMAIL PROTECTED]> Subject: Re: [beanutils] ready for 1.5 > >>> release? > >>> > >>> the patch looks ok. > >>> > >>> since it's a fix for a caching bug and all the caching code is private > >>> to > >>> the class, it's going to be very hard to create a test case without > >>> changing some of the variables from private to package (say). > >> > >> This is an area that I've often wondered about -- how do most people > >> deal with writing unit tests for this sort of stuff? > >> > >> In principle, I think it'd be OK to make things package instead of > >> private, if we also seal the JAR file (i.e. add a "Sealed:" attribute in > >> the manifest) to prevent application classes from declaring themselves > >> into the org.apache.commons.beanutils package and therefore gaining > >> access > >> to these variables. > >> > >>> it shouldn't be too hard to create a test case but the question is > >>> whether it's worth altering the API to do so. if the general feeling is > >>> that a test case for this issue is worth making this change, i'll take > >>> a > >>> look at writing one now. > >>> > >>> - robert > >> > >> Craig > >> > >>> On Friday, October 18, 2002, at 07:29 PM, Scott Sanders wrote: > >>>> With the exception of 12728/12458. > >>>> > >>>> I have not yet looked at creating a test case for it, but I do believe > >>>> the patch is solid. > >>>> > >>>> I have attached it if you get a chance to look at it. > >>>> > >>>> Other than that, I think we are ready. > >>>> > >>>> Scott > >>>> > >>>>> -----Original Message----- > >>>>> From: robert burrell donkin > >>>>> [mailto:robertburrelldonkin@;blueyonder.co.uk] > >>>>> Sent: Friday, October 18, 2002 11:24 AM > >>>>> To: Jakarta Commons Developers List > >>>>> Subject: [beanutils] ready for 1.5 release? > >>>>> > >>>>> > >>>>> are we ready for a beanutils 1.5 release? > >>>>> > >>>>> - robert > >>>>> > >>>>> > >>>>> -- > >>>>> To unsubscribe, e-mail: > >>>>> <mailto:commons-dev-> [EMAIL PROTECTED]> > >>>>> 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: > >>> <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: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
