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 Fri, 29 Aug 2003 18:54:30 GMT
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 null@-
> 
> 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?

-- 

"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


Mime
View raw message