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?
One last thing, I think that the name "getOffendingConfiguration()" should be changed to simply "getConfiguration()".
Cheers, Steve.
Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
Stephen McConnell wrote:
Berin:
While your dealing with this stuff - could you take a look at the problem of the location value assigned to configuration elements that are created implicity. For example - if I have a configuration <configuration/> and I request the child configuration "fred" using config.getChild( "fred" ), I loose the location information when looking up location on the returned child configuration.
What would you like to see?
The whole problem with the dynamically generated items (i.e. configuration
elements that did not originate from the file) is that they don't really
map back to the original file.
We can set the location to something like this:
**DC, parent=${location}**
(DC = dynamically created).
Let me know what you want to see, and I can probably get it going.
A dynamic element should have the same location as the element it is created from.
Basically I have a test case that I want to turn into something useful. At the moment I'm getting this:
Cause: org.apache.avalon.framework.configuration.ConfigurationException
Message: No attribute named "fred" is associated with the configuration element "configuration" at [EMAIL PROTECTED]
I think the error message should be as is but ending with " at " ${location}. And that ${location} should be present for all elements including dynamically created elements.
Having the same location without any modification can be somewhat misleading.
As a compromise I did this:
<dynamic>${location}
So that in your messages you will see this:
Cause: org.apache.avalon.framework.configuration.ConfigurationException Message: No attribute named "fred" is associated with the configuration element "configuration" at null@<dynamic>parent.xml:43:15 ^^^^^^^^^^^^^^^^^^^^^^^^^
Notice the location information. We can easily identify it as a config element that was not in the original document, but we can also find the location of the parent.
The only downside to this is if the dynamically generated element in turn creates another one. Then we would repeat the <dynamic> prefix:
<dynamic><dynamic>parent.xml:43:15
At least we will be able to see how many levels of dynamically generated configs we have....
What do you think?
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
