You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/09/02 15:18:06 UTC
Re: Configuration reporting
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:
<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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Configuration reporting
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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.
I'm not thinking about the path relative to the root of the tree - only
the virtual path commencing from the last locatable concrete element.
This narrows the scope of the problem significantly and allows a utility
class to present error information in a meaninful way. For example, if
a actual element "conf" exists at 10:10 - and apply conf.getChild(
"credentials" ).getChild( "password" ).getValue(), then we get a
configuration exception showing the concrete node location and a virtual
attribute path ./credentials/password/
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[3]: Configuration reporting
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Berin and All!
AT> Just of academical interest: there may some easier ways then using
AT> Stack, for instance a StringBuffer could be used.
<snip/>
AT> With a StringBuffer the amount of memory used will be way less then
AT> for a Stack (in fact it will depend on the depth of the xml tree and
AT> the lenghes of element names).
On the second thought, well, if we package the path with every
configuration element, then really the buffer for our StringBuffer
we be reallocated each time. So in fact this probably will save
NO memory at all. If on the other hand the Stack uses an
String[] array of a proper length under the hood, then using a Stack
will really waste almost no memory, the array will just be filled
with element names (and element names are String that have been
allocated already anyway).
So the real wast of memory here is not maintaining the Stack but
keeping the path information for every element in the Configuration.
So,
1) at the second glance Stack does not look a waste of memory
2) if we're worried about memory (and there may be good benefits
in ultimately pushing Avalon on Java2ME) then we probably could
think about constructing this info at runtime?
Although the current Configuration has no analog of
org.w3c.dom.Node.getParentNode(), it is theoretically
possible to add parent information to Configuration
and then the virtual path could be constructed only on
demand, when there really is an error, not for every node
3) going along these lines it might be also pretty usefull to
keep the filename as a separate string (allocated only once)
and the line and column number as integers and pack this all
into a single location string only on demand - when an error
has happpend, not for every configuration node
Cheers, Anton
P.S. Stephen, you have recently reported that Merlin footprint
is around 2Mb, I wonder how much of this could be saved this way?
Well, probably little, but for J2ME, and keeping in mind that
Configuration is framework, not even a container..
P.P.S. Noel and other administrators, sorry for the mess!
Will try to never post from unsubscribed addresses again,
it was my error!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Configuration reporting
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
Hello!
> Just of academical interest: there may some easier ways then using
> Stack, for instance a StringBuffer could be used.
>
> Flavour 1:
>
> when you need to rip off a path element and you know the length of the
> name of the element that has just been closed, you just shorten the sb
> by this length plus 1 (for the separator)
>
> Flavour 2:
>
> when you need to rip off a path element you just go searching the sb
> from back to the begging untill you find the next separator (the '/'
> char) and shorten the sb by that amount.
>
> With a StringBuffer the amount of memory used will be way less then
> for a Stack (in fact it will depend on the depth of the xml tree and
> the lenghes of element names).
The other issue has to do with dynamically creating the configuration
objects.
For example, if I am creating a tree, I have to create the leaves before
the parent. Since there is no parent created yet, I can only put a guestimated
location path. For example:
DefaultConfiguration leaf = new DefaultCOnfiguration("name","/root/name");
DefaultConfiguration root = new DefaultConfiguration("root","/root");
root.addChild(leaf);
Now what happens when I call the method that creates this configuration
tree, and then add it to another configuration tree?
DefaultConfiguration realRoot = new DefaultConfiguration("problem","/problem");
realRoot.addChild(getConfigFromAbove());
When you look at the path for each element, and traverse the tree, then you
will see something like this:
/problem
/root
/root/name
(indents provided to show the logical relationship).
The path is more troublesome than it is worth unless it is always created
by the DocumentBuilder.
--
"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
Re: Configuration reporting
Posted by Stephen McConnell <mc...@apache.org>.
Anton Tagunov wrote:
>3) going along these lines it might be also pretty usefull to
> keep the filename as a separate string (allocated only once)
> and the line and column number as integers and pack this all
> into a single location string only on demand - when an error
> has happpend, not for every configuration node
>
+1
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[3]: Configuration reporting
Posted by Anton Tagunov <at...@apache.org>.
Hello Berin and All!
AT> Just of academical interest: there may some easier ways then using
AT> Stack, for instance a StringBuffer could be used.
<snip/>
AT> With a StringBuffer the amount of memory used will be way less then
AT> for a Stack (in fact it will depend on the depth of the xml tree and
AT> the lenghes of element names).
On the second thought, well, if we package the path with every
configuration element, then really the buffer for our StringBuffer
we be reallocated each time. So in fact this probably will save
NO memory at all. If on the other hand the Stack uses an
String[] array of a proper length under the hood, then using a Stack
will really waste almost no memory, the array will just be filled
with element names (and element names are String that have been
allocated already anyway).
So the real wast of memory here is not maintaining the Stack but
keeping the path information for every element in the Configuration.
So,
1) at the second glance Stack does not look a waste of memory
2) if we're worried about memory (and there may be good benefits
in ultimately pushing Avalon on Java2ME) then we probably could
think about constructing this info at runtime?
Although the current Configuration has no analog of
org.w3c.dom.Node.getParentNode(), it is theoretically
possible to add parent information to Configuration
and then the virtual path could be constructed only on
demand, when there really is an error, not for every node
3) going along these lines it might be also pretty usefull to
keep the filename as a separate string (allocated only once)
and the line and column number as integers and pack this all
into a single location string only on demand - when an error
has happpend, not for every configuration node
Cheers, Anton
P.S. Stephen, you have recently reported that Merlin footprint
is around 2Mb, I wonder how much of this could be saved this way?
Well, probably little, but for J2ME, and keeping in mind that
Configuration is framework, not even a container..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: Configuration reporting
Posted by Anton Tagunov <at...@apache.org>.
Hello, Berin!
BL> Also, while it is trivial to append strings, pulling the string back
BL> isn't so easy.
BL> For instance:
BL> <root>
BL> <component>
BL> <item>
BL> <element/>
BL> </item>
BL> <item>
BL> <element/>
BL> <item>
BL> </component>
BL> </root>
BL> We can trivially add to the path up until we reach the first close tag.
BL> At that time we have to rip off the current element's portion of the path.
BL> While the logistics can be solved with using a stack, I would like to
BL> avoid over-engineering this.
Just of academical interest: there may some easier ways then using
Stack, for instance a StringBuffer could be used.
Flavour 1:
when you need to rip off a path element and you know the length of the
name of the element that has just been closed, you just shorten the sb
by this length plus 1 (for the separator)
Flavour 2:
when you need to rip off a path element you just go searching the sb
from back to the begging untill you find the next separator (the '/'
char) and shorten the sb by that amount.
With a StringBuffer the amount of memory used will be way less then
for a Stack (in fact it will depend on the depth of the xml tree and
the lenghes of element names).
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org