Finally, onto some Avalon concerns.
Two points:
(a) configuration exceptions would be more useful if they contained the offending fragment
I just updated the ConfigurationException to allow you to include the offending Configuration element in the exception. If the Configuration element is included, you're message will be appended with the location information.
Also the toString() method for the Configuration element was changed from the default "[EMAIL PROTECTED]" to something more useful. For example if we have the following line at line 345 in the config file:
<config>value</config>
The toString() will spit out:
config::value:@config.xml:345:4
i.e.
${name}::${value}:@${location}
If there is no value, it will default to "<no value>".
I also added the Javadocs for the equals/hashcode stuff.
The getMessage() for the ConfigurationException does this:
[EMAIL PROTECTED] if the original configuration object is there.
(b) better specs are needed about component/container seperation of responsibilities (e.g. who handled error reporting)
The problem with specs and standards is that there are so many to choose from. All that is required is to say that the container will log any exception originating from the component during lifecycle operations.
Add a warning that if they choose to log the exception and throw it themselves in the component, that it will result in double-logging the exception.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
