You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Tom Bradford <br...@dbxmlgroup.com> on 2001/09/02 11:01:43 UTC
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Paul Hammant wrote:
> Hypothetical -
>
> If we went ahead with ModifiableConfiguration ConfigurationModifier and Reconfigurable (extends Configurable) would we invoke the update method with a xpath-style ID for the node within the sub-ddocument to change? If yes, we could use dom4j as an interim implmentation (it's very good).
I would try to keep it in the family and just use the Xalan XPathAPI
stuff. I'm skeptible of exposing XPaths as the form for performing
selection against the configuration though, as it assumes (to a degree)
that the underlying representation is XML, when it may not be.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 20:49, Paul Hammant wrote:
> Peter Donald wrote:
> >I was thinking about something as simple as current setup.
> >
> >ie
> >
> >vois storeConfiguration( String application,
> > String block,
> > Configuration config );
>
> Hmm, that forced the comp writer to have some way of constructing an
> tree of Configuration objects themselves. I'd guess getting it right is
> a high art and buckets of code. Though there are good points raised
> about reliance on Xpath and it's implicit underlying XML document, I
> think it's a simple think for component writers to use.
Well we could always add a helper class. Something like
MutableConfiguration config = ConfigurationHelper.clone( readOnlyConfig );
ConfigurationHelper.set( "client-connections/connection[@name='ssl']/@auth",
"true" );
repo.storeConfiguration( myApp, "connections", config );
This would be simplified if we used something like the recent XPath APIs in
commons or on sourceforge. Some of them work on multiple doc types (ie
DOM/JDOM/DOM4J/JavaBeans). Look for jxpath in commons I think.
Re: dom4j license issues.
Ask the author (who is also a member of commons-dev IIRC) and I am sure they
would be willing to help fix whatever needs doing.
--
Cheers,
Pete
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>>> cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
>>
>> setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
>
>Thanks for the refocusing comment above. My question
>is, "who is responsible for setting the
>configuration?"
>The point being, with the IoC pattern (see site docs
>for those not familiar), the Configuration is given as
>a read only instance for a reason. The Configurable
>Component is not supposed to alter the system beneath
>it in the Component heirarchy. With that in mind, we
>have to consider exactly what types of configuration
>changes are occuring, the affect on the system, and
>which component/service is responsible for altering
>the
>configuration.
>
Yes it's true that Configurable gived a read-only configuration, but if
the block......
1) implements ConfigurationModifier,
2) specifies which Configuration nodes it will be seeking to have
modification rights for, in it's assembly.xml,
3) is then handed a ModifiableConfiguration during startup,
4) call invoke getChild("x").getChild("y").setLongValue(14) on that
only, not it's own Configuration.
..... does that still break the IoC design goals?
>It is probable that the dbXML folks have thought many
>of these things through, so I am very interested in
>the approach and thought processes they have gone
>through for their system.
>
>It could be that we should develop a special purpose
>configuration management service that manages the
>persistence of the Configuration elements. In that
>case we programmatically build what we _want_ the
>configuration to be (i.e. the current method building
>configuration trees) and register it with the
>Configuration Management Service. The service would
>be an Avalon Block in CornerStone.
>
Sounds superior to the above...
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Berin Loritsch <bl...@yahoo.com>.
--- Paul Hammant <Pa...@yahoo.com> wrote:
> >
> >
> >[... Xpath complex & room for plenty of error ...]
> >
> Conceeded.
>
> >
> >Another possibility, is to just stick with method
> calls (ex):
> >
>
>cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
> >
> That's what Configurable gives already. We're
> dwelling on the setting
> of config rather than the getting of it in this
> discussion.
>
>
>
setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
> How that?
Thanks for the refocusing comment above. My question
is, "who is responsible for setting the
configuration?"
The point being, with the IoC pattern (see site docs
for those not familiar), the Configuration is given as
a read only instance for a reason. The Configurable
Component is not supposed to alter the system beneath
it in the Component heirarchy. With that in mind, we
have to consider exactly what types of configuration
changes are occuring, the affect on the system, and
which component/service is responsible for altering
the
configuration.
It is probable that the dbXML folks have thought many
of these things through, so I am very interested in
the approach and thought processes they have gone
through for their system.
It could be that we should develop a special purpose
configuration management service that manages the
persistence of the Configuration elements. In that
case we programmatically build what we _want_ the
configuration to be (i.e. the current method building
configuration trees) and register it with the
Configuration Management Service. The service would
be an Avalon Block in CornerStone.
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> >cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
> >
> That's what Configurable gives already. We're dwelling on the setting
> of config rather than the getting of it in this discussion.
Yeah, I know... It's a simple, straight-forward approach, which is why
I suggested sticking with it. Should have use the setValue as an
example instead of getValue...
> setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
> How that?
Fine by me. Another thing that we do in our configuration system is the
idea of a ConfigurationCallback interface, so for example:
colConfig.processChildren("collection",
new ConfigurationCallback() {
public void process(Configuration cfg) throws dbXMLException {
Collection col = new
Collection((Collection)CollectionManager.this);
col.setConfig(cfg);
collections.put(col.getName(), col);
}
});
This would behave in a similar fashion to getting the child set by name
except that there wouldn't be the additional overhead of having to
produce an array and then iterate over it.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>[... Xpath complex & room for plenty of error ...]
>
Conceeded.
>
>Another possibility, is to just stick with method calls (ex):
>
>cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
>
That's what Configurable gives already. We're dwelling on the setting
of config rather than the getting of it in this discussion.
setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
How that?
- PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
>
> Peter Donald wrote:
>
> >I was thinking about something as simple as current setup.
> >
> >ie
> >
> >vois storeConfiguration( String application,
> > String block,
> > Configuration config );
> >
> Hmm, that forced the comp writer to have some way of constructing an
> tree of Configuration objects themselves. I'd guess getting it right is
> a high art and buckets of code. Though there are good points raised
> about reliance on Xpath and it's implicit underlying XML document, I
> think it's a simple think for component writers to use.
There are issues beyond that as well. XPath is in no way simple. It's
actually a potentially very complex and highly flexible language that
maps well to XML documents, but not necessary well to non-XML
structures. It's definitely not easy to write an XPath implementation
(as the Xalan people). Beyond that, there are other issues, like the
nature of selectors, for example:
//node()
Is a perfectly valid XPath selector that recursively selects *every*
node in a tree. This includes elements, attributes, text, cdata,
comments, etc.... If you were to use this XPath as a selector for
performing a modification to a tree, you'd end up touching the entire
tree, which could be very bad. There are also the functions that return
non-nodesets, and may modify the values of the returned values in the
process.
I would propose a terse, simplified pathing system that does not support
functions, all-descendent/ancestor axis, and many of the other nice
features of XPath that neither translate well to a configuration model,
or translate well to a non-XML structure.
Another possibility, is to just stick with method calls (ex):
cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
For two reasons:
1 - Though verbose, it provides the same functionality a terse pathing
form would.
2 - It's structural validity can be qualified at compile-time.. XPath
would require run-time validation.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter Donald wrote:
>I was thinking about something as simple as current setup.
>
>ie
>
>vois storeConfiguration( String application,
> String block,
> Configuration config );
>
Hmm, that forced the comp writer to have some way of constructing an
tree of Configuration objects themselves. I'd guess getting it right is
a high art and buckets of code. Though there are good points raised
about reliance on Xpath and it's implicit underlying XML document, I
think it's a simple think for component writers to use.
<aside short="Crossed the same bridge with Jesktop">
I'm mentioning it becuase Jesktop now has Configlets - e.g.
BackdropConfigket being one such publisher of XML. The subscriber to
the backdrop config (XML) is the WindowManager. The publisher makes
changes as it's visible in ControlPanel and the changes are forwarded on
to the WindowManager for acting upon. For Configlets writing xml is
pain. So much so that I also created Configlets that deal in serialized
objects. I was toying with Dom4JConfiglet but that raised license issues.
</aside>
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 19:01, Tom Bradford wrote:
> Paul Hammant wrote:
> > Hypothetical -
> >
> > If we went ahead with ModifiableConfiguration ConfigurationModifier and
> > Reconfigurable (extends Configurable) would we invoke the update method
> > with a xpath-style ID for the node within the sub-ddocument to change?
> > If yes, we could use dom4j as an interim implmentation (it's very good).
>
> I would try to keep it in the family and just use the Xalan XPathAPI
> stuff. I'm skeptible of exposing XPaths as the form for performing
> selection against the configuration though, as it assumes (to a degree)
> that the underlying representation is XML, when it may not be.
I was thinking about something as simple as current setup.
ie
vois storeConfiguration( String application,
String block,
Configuration config );
I haven't really thought about how logging/security/threading can be
reconfigured. Those changes would require an app shutdown - while changing a
blocks configuration does not require that.
As I have hinted at in past I really really want to have one ConfigRepository
stored in a directory (ala LDAP) to ease management.
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org