avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Configuration reporting
Date Tue, 02 Sep 2003 13:18:06 GMT
Stephen McConnell wrote:
> 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:


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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message