Berin:
I think we are heading in a positive direction (identity propergation is good) but I'm not too happy with the details. The are a couple of problems I have with the new variant - firstly: the resulting text is not (IMHO) very useful:
Cause: org.apache.avalon.framework.configuration.ConfigurationException
Message: No attribute named "fred" is associated with the configuration element
"configuration" at null@<generated>file: /F:/dev/forced-error/block.xml:13:63
I think we need to consider this problem more formally. We can assume that any "real" configuration element is identifiable by its (a) file, (b) location within the file, and (c) virtual path relative to the identifiable anchor element.
E.g.:
source = file:///F:/dev/forced-error/block.xml position = 13:63 virtual-path = /configuration
Currently the "standard" response from getLocation is the string [filename]:[line]:[column]. I think we should keep this as is (ie. maintain classic avalon output). However, I think we could compliment classic avalon with something like the following operation on Configuration:
Location getLocationDescriptor();
Where a Location looks something like:
public final class Location { public URL getSource() // return a url to the source public int getLineIndex(); // return the line number public int getColumnIndex(); // return the column number public String getVirtualPath(); // return the relative virtual path }
The getVirtualPath() is really the only thing new in the above. It is the path of virtually created configuration instances relative to the locatable concrete element. This gives us sufficient information to present the original source, and to reconstruct the virtual configuration logic.
Thoughts?
The virtual path is not as easy to produce. I mean how do you propose it to be done? If something is /root/component/item/element are we always referring to the root or the component as the base of the tree. Remember the tree can be split for this very purpose.
Also, while it is trivial to append strings, pulling the string back isn't so easy.
For instance:
<root>
<component>
<item>
<element/>
</item>
<item>
<element/>
<item>
</component>
</root>We can trivially add to the path up until we reach the first close tag. At that time we have to rip off the current element's portion of the path. While the logistics can be solved with using a stack, I would like to avoid over-engineering this.
How would the LocationDescriptor be used? Would the extra object in the configuration hierarchy be truly helpful? What would be the memory usage for the thing?
One last thing, I think that the name "getOffendingConfiguration()" should be changed to simply "getConfiguration()".
Easily done.
--
"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]
