Hi Bill,
You are quite correct. The logic stems from my original ConfigurationDynaBean which used "lazy" logic to determine if a property existed in a dynabean (I will be releasing a lazy version of the configu dynabean soon). If you could create an issue in bugzilla I will generate a patch for this.
Kind regards -- rg
Bill Vollers wrote:
I have a question about the behavior of ConfigurationDynaBean. I'm not sure what the intended behavior should be, but looking at the code in the CVS repository makes me think the intent is different from the current behavior. However, it appears this is fairly new code, so I don't know if the problem is in the code behavior or if I am just misinterpreting the intent from the code.
In looking at the code, it appears the intent was for the get method to throw an IllegalArgumentException in the case where the desired property does not exist in the backing Configuration instance. This would cause the method to meet the specification of get in the DynaBean interface. However, get only throws the exception if the specified name is null. If the name is non-null but does not exist, then an empty ConfigurationDynaBean is returned.
The reason for this is in the call to configuration.subset in the get method. The relevant code is shown below (this is version 1.2 from the CVS repository):
// get configuration property Object result = configuration.getProperty(name); if(result == null && name != null) { // otherwise attempt to create bean from configuration subset Configuration subset = configuration.subset(name); if(subset != null) result = new ConfigurationDynaBean(configuration.subset(name)); }
If the extracted subset is not null, then a new ConfigurationDynaBean is constructed from that subset. However, I don't think Configuration.subset ever returns null. If no properties from the configuration begin with the specified prefix, then the return value from subset is an empty Configuration, not null (this is true even if the prefix argument is null). Therefore, the "if(subset != null)" test always succeeds in the above code, and result is always set to a new ConfigurationDynaBean.
The only way result will remain null is if it is set to null in the initial configuration.getProperty() call, and then if it bypasses the if-clause by having (name == null). Therefore, that is the only case where the exception is thrown.
I didn't notice any JUnit test cases for checking the behavior when accessing a non-existing property name (although there is a case for a null name).
So, my question is: should the get method throw an exception when called with a non-existent property name? If so, then the get method needs to be changed. If not, I might recommend documenting this difference from the DynaBean interface in some way, and perhaps changing the above code to remove the superfluous if-test. I'd be happy to assist if needed.
-- Bill Vollers
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
