You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/02/27 18:40:22 UTC
CascadingConfiguration --> framework ?
What do people think about moving the class CascadingConfiguration
from cornerstone/apps/orb to avalon/framework/configuration?
The class is basically an implementation of Configuration that
takes a primary and default configuration as constructor arguments.
Resolution of attribute values and child elements are resolved
against the primary configuration - and if that fails, the
implementation attempt to resolve the request against the
secondary default configuration (which could be another
CascadingConfiguration). Resolution of children for a particular
"name" result in the aggregation of the primary and default
configuration child elements.
Thoughts ?
Cheers, Steve.
---------------------------------------------------------
Stephen McConnell wrote:
> I think it [CascadingConfiguration] would make a good
> addition to the framework/configuration package as it not
> dependent on any other packages.
Torsten Curdt wrote:
> Cool... Since I'm no avalon committer - could you do it then, please?
> Let me know if I can help...
Shawn Boyce wrote:
> I agree. It looks useful and I can make use of it in my service.
> It can replace some existing code that does basically the same thing.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CascadingConfiguration --> framework ?
Posted by Stephen McConnell <mc...@apache.org>.
Hi Pete:
Reading your reply I get the impression your thinking about something
different to what is being proposed. The proposal concerns the
CascadingConfiguration implementation for the apps/enterprise/orb
package - it is not related to the earlier activitiy of attempting
to incorporate a structural reference to a parent configuration.
See notes in-line.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, 28 February, 2002 09:07
> To: Avalon Developers List
> Subject: Re: CascadingConfiguration --> framework ?
>
>
> On Thu, 28 Feb 2002 08:03, Torsten Curdt wrote:
> > On Thu, 28 Feb 2002, Peter Donald wrote:
> > > On Thu, 28 Feb 2002 04:40, Stephen McConnell wrote:
> > > > What do people think about moving the class CascadingConfiguration
> > > > from cornerstone/apps/orb to avalon/framework/configuration?
> > >
> > > Same as I thought last time you asked - ie erk. Until there can be a
> > > generic intuitive and simple mechanism it should not go into
> > > framework.
The CascadingConfiguration implementation DOES provide a generic, intuitive
and simple mechanism. I'm not sure what your looking at but its not what
your describing. Can you identify one single operation in the
CascadingConfiguration implementation which is not 100% consistent with
the interface spec, and 100% consistent with a generally expected result?
> > ...if you can come up with something better ;)
>
> I don't it a problem with a simple solution.
>
> > After this discussion I doubt there is a more "intuitive" and
> > "intelligent" way of doing this.
>
> Berin once proposed a Rules based mechaism that was fairly
> intuitive IIRC -
> never got beyond prototyping stage though.
>
> > ...but hey, there is something that works - at least for the most
> > use-cases.
>
> you sure? There aint nothing that I have been presented with that
> covers any of my needs.
Pete - are you "really" looking at the same thing.
I'm suprised! I think maybe your assuming this proposal concerns the
patch to AbstractConfiguration that I raised issue about. Its not that
- it the CascadingConfiguration implemenmtation that has been well and
try validated.
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CascadingConfiguration --> framework ?
Posted by Peter Donald <pe...@apache.org>.
On Thu, 28 Feb 2002 08:03, Torsten Curdt wrote:
> On Thu, 28 Feb 2002, Peter Donald wrote:
> > On Thu, 28 Feb 2002 04:40, Stephen McConnell wrote:
> > > What do people think about moving the class CascadingConfiguration
> > > from cornerstone/apps/orb to avalon/framework/configuration?
> >
> > Same as I thought last time you asked - ie erk. Until there can be a
> > generic intuitive and simple mechanism it should not go into framework.
>
> ...if you can come up with something better ;)
I don't it a problem with a simple solution.
> After this discussion I doubt there is a more "intuitive" and
> "intelligent" way of doing this.
Berin once proposed a Rules based mechaism that was fairly intuitive IIRC -
never got beyond prototyping stage though.
> ...but hey, there is something that works - at least for the most
> use-cases.
you sure? There aint nothing that I have been presented with that covers any
of my needs.
> And there are a couple of people beeing thankful for this
> addition.
>
> Pete, do you really give a -1 or is this more a -0?
-1 to putting in framework. If someone wants they can chuck it in excalibur
scratchpad and then move to excalibur propoer when it is more thouroughly
utilized.
--
Cheers,
Pete
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CascadingConfiguration --> framework ?
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 28 Feb 2002, Peter Donald wrote:
> On Thu, 28 Feb 2002 04:40, Stephen McConnell wrote:
> > What do people think about moving the class CascadingConfiguration
> > from cornerstone/apps/orb to avalon/framework/configuration?
>
> Same as I thought last time you asked - ie erk. Until there can be a generic
> intuitive and simple mechanism it should not go into framework.
...if you can come up with something better ;)
After this discussion I doubt there is a more "intuitive" and
"intelligent" way of doing this. At least - not for a generic XML
structure. The only reason why we might expect something else is because
we *understand* the structure we are trying "merge" or "cascade". I don't
think there can be a generic sollution for this problem.
...but hey, there is something that works - at least for the most
use-cases. And there are a couple of people beeing thankful for this
addition.
Pete, do you really give a -1 or is this more a -0?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CascadingConfiguration --> framework ?
Posted by Peter Donald <pe...@apache.org>.
On Thu, 28 Feb 2002 04:40, Stephen McConnell wrote:
> What do people think about moving the class CascadingConfiguration
> from cornerstone/apps/orb to avalon/framework/configuration?
Same as I thought last time you asked - ie erk. Until there can be a generic
intuitive and simple mechanism it should not go into framework.
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CascadingConfiguration --> framework ?
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Thursday, 28 February, 2002 07:38
> To: Avalon Developers List
> Subject: RE: CascadingConfiguration --> framework ?
>
>
> > The class is basically an implementation of Configuration that
> > takes a primary and default configuration as constructor arguments.
> > Resolution of attribute values and child elements are resolved
> > against the primary configuration - and if that fails, the
> > implementation attempt to resolve the request against the
> > secondary default configuration (which could be another
> > CascadingConfiguration). Resolution of children for a particular
> > "name" result in the aggregation of the primary and default
> > configuration child elements.
> >
> > Thoughts ?
>
> Why not make CascadingConfiguration the "primary" as well?
The constructor just takes a Configuration as an arguement for
the primary and fallback configuration. So in-effect, you can
supply a cascading or classic configuration for either. The
implementation does not make a destinctioin between cascading
and classic configurations because the behaviour is exactly that
of a class Configuration instance.
Cheers, Steve.
> ie
>
> CascadingConfiguration
> {
> CascadingConfiguration( Configuration parent ) {}
>
> String getAtrribute( String attributeName )
> {
> if( hasAttribute(attributeName) )
> // return local;
> else
> {
> if( parent != null )
> return parent.getAttribute ( String
> attributeName );
> else
> return null;
> }
> }
> }
>
> or something along those lines. This way, you can even just add
> the extra constructor to DefaultConfiguration and modify its
> behaviour so that it cascades if a parent is provided. Seems
> more intuitive to me.
>
> grz,
>
> - LSD
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CascadingConfiguration --> framework ?
Posted by Leo Simons <ma...@leosimons.com>.
> The class is basically an implementation of Configuration that
> takes a primary and default configuration as constructor arguments.
> Resolution of attribute values and child elements are resolved
> against the primary configuration - and if that fails, the
> implementation attempt to resolve the request against the
> secondary default configuration (which could be another
> CascadingConfiguration). Resolution of children for a particular
> "name" result in the aggregation of the primary and default
> configuration child elements.
>
> Thoughts ?
Why not make CascadingConfiguration the "primary" as well?
ie
CascadingConfiguration
{
CascadingConfiguration( Configuration parent ) {}
String getAtrribute( String attributeName )
{
if( hasAttribute(attributeName) )
// return local;
else
{
if( parent != null )
return parent.getAttribute ( String attributeName );
else
return null;
}
}
}
or something along those lines. This way, you can even just add
the extra constructor to DefaultConfiguration and modify its
behaviour so that it cascades if a parent is provided. Seems
more intuitive to me.
grz,
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>