At 13:15 11.06.2002 -0700, you wrote: > > >Ack! I know there is a bug lurking there somewhere. I > > can't wait to find > > >it. :-) > > > > Hint: It's not a logic bug. It is related JavaBeans introspection. A > > test case soliciting a configurator should reveal the problem. > >Heh. I know what you are talking about on the MatchFilterBase class. When >I did it, I was wondering if the Bean Property/OptionHandler would be able >to deal with it.
Concretely, introspection cannot deal with a class having two setter methods with the same name that differ only in parameter type. Examples: setNoMatchReturnValue(String filterReturnValue) setNoMatchReturnValue(int filterReturnValue) setMatchReturnValue(String filterReturnValue) setMatchReturnValue(int filterReturnValue) My guess is that NoMatchReturnValue and MatchReturnValue will not be properly recognized as valid options by log4j configurators. >I have written code myself that when the basic bean >introspection fails (because there is no matching getter/setter) it falls >back to searching and calling the desired version of the method directly. That's an interesting approach. I had not thought of it. >I'll be sure to work it out. And the test case would not have caught this >problem unless it was written to use a configuration file to set up the >appender and filters. I'm thinking that using a configuration file should >be part of the test case to get full coverage. Perfect. >-Mark -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
