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 2001/09/25 15:40:52 UTC
Proposed change to Parameters:
Axis has a consept for options (equivalent to our parameters)
that our existing Parameters object does not satisfy. It is
the concept of "locked" parameters.
The approach is in between the two states our Parameters object
can handle. Currently we have completely modifiable or read only.
The change would allow the markup to be changed to:
<parameter name="foo" value="bar" locked="true"/>
<parameter name="baz" value="vip"/>
The additional parameter (if present) will lock a parameter no
matter what state the object is in.
That way, a run-time system can have parameters that are modified
at specific times--but keep certain params from changing during
the life of the system.
There are two other things I would like to see: A Reparameterizable
interface (to compliment Reconfigurable), and a "fromConfiguration"
method that allows you to specify the element name for a parameter.
The attributes would be the same, but a project would be able to
use the name "option" instead of "parameter" if it wanted to.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Peter Donald <do...@apache.org>.
On Thu, 27 Sep 2001 00:14, Berin Loritsch wrote:
> > Configuration data is configuration data regardless of whether it is flat
> > or hierarchial. You are prposing that the config data be partially
> > mutable (Like making some of Configuration objects mutable but not others
> > in a config). This is not something we should support IMO - hence the -1
> > on it ;)
>
> Point taken. However, we also have been talking about mutable
> configurations. there does need some control over what can be modified and
> what cannot be modified.
Agreed. ParameterSchema and ConfigurationSchema that adapt to exisitng APIs
if possible. (ie one ConfigurationSchema impl would use DTD and one would use
XSchema). Thats how I want to see it done long term.
> We can take the approach that the Component handles that responsibility.
+1
> However, this is not automatic, and does not
> provide a mechanism for a parent to force its will over its children--IoC.
I am not sure what you mean. The component requests from it's container that
it wants a mutable copy of its own config data, modifies it and then passes
it back to it's container. The container will validate using above schema and
if it passes then everything is good.
At least thats what my understanding of it was. This was based on your work
of rul based validation from ages ago combined with some of the things I have
been looking at lately. Am I missing something?
> > > Getting back to setting up the Parameter object, it
> > > is terribly inconvenient to do the hierarchical approach. Plus, you
> > > have an undefined action when you merge Parameters.
> > >
> > > For instance:
> > >
> > > Parameters testcase = new Parameters();
> > > Parameters mergecase = new Parameters();
> > > mergecase.setParameter("merge", "case");
> > > mergecase.makeReadOnly();
> > >
> > > testcase.merge(mergecase);
> > > testcase.setParameter("merge", "value");
> > >
> > > "value".equals(testcase.getParameter("merge")) == true // This is what
> > > we don't want!
> >
> > then you swap the order of merge and setParameter()?
>
> Keep in mind this example is contrived, and does not reflect the scenario
> where a Parameterizable component keeps its own copy of a Parameters object
> and simply merges the contents (i.e. with a read-only Parameters object
> that the parent was careful to make read only).
Okay thats not what I am proposing. I was proposing that the merging all
occurs in parent space and the child only gets a copy of final Parameters
object. The parent gets to do merging and all tricky stuff and child is given
simple interface.
Is there any reason why this wouldn't work?
> My point becomes even more clear when we have Reparameterizable in the
> picture because you will be merging the Parameters given to you with
> an existing set.
I don't see Re* as a merge operation but a replace operation for all systems
(CM, Config, Parameters and Context).
> > > Requiring other projects to either change their configuration schemes
> > > or reimplement ( extend or whatever ) parameters objects simply so they
> > > can change what they call a parameter is kind of rediculous.
> >
> > Changing Framework to reflect different configuration schemes for every
> > different project Avalon is used in is ludicrous.
>
> (I withheld using the word ludicrous ;-)
;)
> We are not changing the _framework_. I want to make that clear. What I am
> proposing is adding _functionality_ to the framework _without_changing_
> existing behavior.
right. However what I am saying is that it is not a general enough concern.
Much like ExcaliburComponentManager is not as general as
DefaultComponentManager and is thus not kept in framework CVS but in
excalibur CVS.
I don't see these functionalities as sufficiently general enough to warrant
addition to the framework CVS. I wouldn't mind it being placed in Excalibur
but definetly not in Framework.
> > I have a configuration scheme like Axis. Options however have other
> > features. They can be "archive" options (will be written out when saving
> > options), they can be "noset" (not able to be set by normal code), they
> > can be "latch" (only able to be set within a specific phase),
> > "serverinfo" (replicated to clients), "clientinfo" (replicated to
> > server), etc
> >
> > How many would I get to add to Avalons Parameters object? All of them,
> > some of them, none of them?
>
> We need to evaluate the change as we are doing here. If they are
> applicable in more than one setting than we have a winner.
I would not agree with this. I would say that if the feature is common to a
wide variety of scenarios, is simple and focused then it belongs in Framework
otherwise it doesn't. ie ExcaliburCM is suitable in a range of scenarios but
it is not simple, small and focused and hence lives in Excalibur.
> Your "noset"
> option is exactly like the "locked" option in Axis. You have proved my
> point that the partially writable Parameters object is useful in more than
> one setting.
I think you missed my point. Almost any functionality you can describe is
useful in multiple scenarios. We don't want to add it all into Avalon though
because kitchen-sink programming is not simple to understand, maintain and
keep focused.
> A framework should be designed so that there are simple methods for the
> majority of cases. However, it should also be extended as more use cases
> are found. If adding special methods to change the name of an element
> and arguable even attributes does not change the simple case and allows
> customization for the special case, then it should be considered.
Who said it wasn't considered. I looked at it and decided I didn't like it ;)
It's not that it is not useful code. It is just not useful enough to warrant
the complexity adding this sort of thing tends to require.
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Wed, 26 Sep 2001 07:00, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:
> > > Right. But fundamentally I don't think we should be supporting partial
> > > mutability in any sort of configuration data. We don't have partially
> > > mutable Config trees and I don't think we should support it.
> >
> > I'm not talking about config trees. I am talking about Parameters.
> > Inherently flat data.
>
> Configuration data is configuration data regardless of whether it is flat or
> hierarchial. You are prposing that the config data be partially mutable (Like
> making some of Configuration objects mutable but not others in a config).
> This is not something we should support IMO - hence the -1 on it ;)
Point taken. However, we also have been talking about mutable configurations.
there does need some control over what can be modified and what cannot be
modified. We can take the approach that the Component handles that responsibility.
However, this is not automatic, and does not provide a mechanism for a parent
to force its will over its children--IoC.
> > Getting back to setting up the Parameter object, it
> > is terribly inconvenient to do the hierarchical approach. Plus, you have
> > an undefined action when you merge Parameters.
> >
> > For instance:
> >
> > Parameters testcase = new Parameters();
> > Parameters mergecase = new Parameters();
> > mergecase.setParameter("merge", "case");
> > mergecase.makeReadOnly();
> >
> > testcase.merge(mergecase);
> > testcase.setParameter("merge", "value");
> >
> > "value".equals(testcase.getParameter("merge")) == true // This is what we
> > don't want!
>
> then you swap the order of merge and setParameter()?
Keep in mind this example is contrived, and does not reflect the scenario
where a Parameterizable component keeps its own copy of a Parameters object
and simply merges the contents (i.e. with a read-only Parameters object that
the parent was careful to make read only).
In that case, your glib remark cannot apply. The order I presented was
important to demonstrate my point. If the parameter objects are already
merged by the time I want to set "merge" to "value", but the parent wants
the data to be a constant, then I will overwrite the "constant". This is
not good behavior.
My point becomes even more clear when we have Reparameterizable in the
picture because you will be merging the Parameters given to you with
an existing set.
> > The implementation that I propose is able to lock all parameters
> > in a read-only Parameters object--even when merged with a non-read-
> > only parameters object.
>
> The functionality you propose partially readable and partially writeable data
> in the same object. It is not needed functionality as it can be implemented
> as I have indicated without any changes to current framework setup.
As I pointed out, there are some serious holes in your approach, that my
approach solves predictably. I guarantee you that someone (not as careful
as you) will run into problems using your approach.
> > Requiring other projects to either change their configuration schemes or
> > reimplement ( extend or whatever ) parameters objects simply so they can
> > change what they call a parameter is kind of rediculous.
>
> Changing Framework to reflect different configuration schemes for every
> different project Avalon is used in is ludicrous.
(I withheld using the word ludicrous ;-)
We are not changing the _framework_. I want to make that clear. What I am
proposing is adding _functionality_ to the framework _without_changing_ existing
behavior.
> I have a configuration scheme like Axis. Options however have other features.
> They can be "archive" options (will be written out when saving options), they
> can be "noset" (not able to be set by normal code), they can be "latch" (only
> able to be set within a specific phase), "serverinfo" (replicated to
> clients), "clientinfo" (replicated to server), etc
>
> How many would I get to add to Avalons Parameters object? All of them, some
> of them, none of them?
We need to evaluate the change as we are doing here. If they are applicable
in more than one setting than we have a winner. Your "noset" option is exactly
like the "locked" option in Axis. You have proved my point that the partially
writable Parameters object is useful in more than one setting.
As to the others: currently we have to consider all parameters to be "archive"
options unless we specify otherwise. It can be argued that the Component
needs to manage what gets archived or not. However, an outomatic mechanism
also helps to simplify using the Parameters. Next, parameters are "latch"
parameters if "makeReadOnly()" is called later. The Parameters object is
stateless--so "latch" parameters would only be useful in a StatefulParameters
object. The "*info" parameters are sufficiently application specific to
not go into any detail here.
The only difference between "noset" and "locked" is the attribute name used
for them.
> > Adding the ability to identify the attribute names is FS (flexibility
> > syndrome).
>
> as is adding ability to modify element names. It is a product specific demand
> to why not place it in the product and not in the framework that is meant to
> be generalized.
A framework should be designed so that there are simple methods for the
majority of cases. However, it should also be extended as more use cases
are found. If adding special methods to change the name of an element
and arguable even attributes does not change the simple case and allows
customization for the special case, then it should be considered.
A framework needs to be well thought out. This is true. It should not be
so set in stone that it is archane before you begin. Configuration is something
that we don't have perfect yet, and it should something where we need to
evaluate new approaches as needs arrise.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 07:00, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:
> > > > I am fairly sure I don't like this. If parts are read-only and parts
> > > > are read-write then IMHO they should not be part of same Parameters
> > > > object. A possible solution to get around this would be to allow
> > > > Parameters to have a parent and make it possible to specify who to
> > > > read properties from first. (This would mean that properties were
> > > > always accessed from parent first and then from child or vice versa).
> > > > So you would have something like
> > > >
> > > > Parameters parent = new Parameters();
> > > > ...setup immutable variables here...
> > > > parent.makeReadOnly();
> > > >
> > > > Parameters child1 = new Parameters( parent, false );
> > > > ...setup non "locked" parameters here...
> > > >
> > > > Then later on
> > > >
> > > > Parameters child2 = new Parameters( parent, false );
> > > > child2.merge( child 1 );
> > > > ...setup non "locked" parameters here for second time...
> > > >
> > > > Actually this is what I partially do in quite a few of my apps. But I
> > > > do it manually and instead of using term parent I use term defaults
> > > > ;)
> > >
> > > There are three issues with your approach:
> > >
> > > 1) If the parent is accessed first, then you can never change the value
> > > of a parameter. Parameters will always return the value of the parent.
> >
> > You mean the parents values are immutable/locked. Isn't that what you
> > wanted?
>
> yes, but again, see below.
>
> > > 3) When deriving your Parameters object from a Configuration object
> > > set, you cannot determine which are meant to be locked, and which are
> > > allowed to be changed. Instead you are forced to have the parameters
> > > specified in two locations. This makes automatic incorporation in
> > > Excalibur's
> > > ComponentManager near impossible.
> >
> > Right. But fundamentally I don't think we should be supporting partial
> > mutability in any sort of configuration data. We don't have partially
> > mutable Config trees and I don't think we should support it.
>
> I'm not talking about config trees. I am talking about Parameters.
> Inherently flat data.
Configuration data is configuration data regardless of whether it is flat or
hierarchial. You are prposing that the config data be partially mutable (Like
making some of Configuration objects mutable but not others in a config).
This is not something we should support IMO - hence the -1 on it ;)
> Getting back to setting up the Parameter object, it
> is terribly inconvenient to do the hierarchical approach. Plus, you have
> an undefined action when you merge Parameters.
>
> For instance:
>
> Parameters testcase = new Parameters();
> Parameters mergecase = new Parameters();
> mergecase.setParameter("merge", "case");
> mergecase.makeReadOnly();
>
> testcase.merge(mergecase);
> testcase.setParameter("merge", "value");
>
> "value".equals(testcase.getParameter("merge")) == true // This is what we
> don't want!
then you swap the order of merge and setParameter()?
> The implementation that I propose is able to lock all parameters
> in a read-only Parameters object--even when merged with a non-read-
> only parameters object.
The functionality you propose partially readable and partially writeable data
in the same object. It is not needed functionality as it can be implemented
as I have indicated without any changes to current framework setup.
> Requiring other projects to either change their configuration schemes or
> reimplement ( extend or whatever ) parameters objects simply so they can
> change what they call a parameter is kind of rediculous.
Changing Framework to reflect different configuration schemes for every
different project Avalon is used in is ludicrous.
I have a configuration scheme like Axis. Options however have other features.
They can be "archive" options (will be written out when saving options), they
can be "noset" (not able to be set by normal code), they can be "latch" (only
able to be set within a specific phase), "serverinfo" (replicated to
clients), "clientinfo" (replicated to server), etc
How many would I get to add to Avalons Parameters object? All of them, some
of them, none of them?
> Adding the ability to identify the attribute names is FS (flexibility
> syndrome).
as is adding ability to modify element names. It is a product specific demand
to why not place it in the product and not in the framework that is meant to
be generalized.
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:
> > > I am fairly sure I don't like this. If parts are read-only and parts are
> > > read-write then IMHO they should not be part of same Parameters object. A
> > > possible solution to get around this would be to allow Parameters to have
> > > a parent and make it possible to specify who to read properties from
> > > first. (This would mean that properties were always accessed from parent
> > > first and then from child or vice versa). So you would have something
> > > like
> > >
> > > Parameters parent = new Parameters();
> > > ...setup immutable variables here...
> > > parent.makeReadOnly();
> > >
> > > Parameters child1 = new Parameters( parent, false );
> > > ...setup non "locked" parameters here...
> > >
> > > Then later on
> > >
> > > Parameters child2 = new Parameters( parent, false );
> > > child2.merge( child 1 );
> > > ...setup non "locked" parameters here for second time...
> > >
> > > Actually this is what I partially do in quite a few of my apps. But I do
> > > it manually and instead of using term parent I use term defaults ;)
> >
> > There are three issues with your approach:
> >
> > 1) If the parent is accessed first, then you can never change the value of
> > a parameter. Parameters will always return the value of the parent.
>
> You mean the parents values are immutable/locked. Isn't that what you wanted?
yes, but again, see below.
> > 3) When deriving your Parameters object from a Configuration object set,
> > you cannot determine which are meant to be locked, and which are allowed to
> > be changed. Instead you are forced to have the parameters specified in two
> > locations. This makes automatic incorporation in Excalibur's
> > ComponentManager near impossible.
>
> Right. But fundamentally I don't think we should be supporting partial
> mutability in any sort of configuration data. We don't have partially mutable
> Config trees and I don't think we should support it.
I'm not talking about config trees. I am talking about Parameters. Inherently
flat data. Getting back to setting up the Parameter object, it is terribly
inconvenient to do the hierarchical approach. Plus, you have an undefined
action when you merge Parameters.
For instance:
Parameters testcase = new Parameters();
Parameters mergecase = new Parameters();
mergecase.setParameter("merge", "case");
mergecase.makeReadOnly();
testcase.merge(mergecase);
testcase.setParameter("merge", "value");
"value".equals(testcase.getParameter("merge")) == true // This is what we don't want!
The implementation that I propose is able to lock all parameters
in a read-only Parameters object--even when merged with a non-read-
only parameters object.
> > > > and a "fromConfiguration"
> > > > method that allows you to specify the element name for a parameter.
> > > > The attributes would be the same, but a project would be able to
> > > > use the name "option" instead of "parameter" if it wanted to.
> > >
> > > Seems kinda ugly to me.
> >
> > If you have a better way of implementing the same thing let me know. The
> > thing is that we are forcing all configuration schemes to be the same. The
> > new fromConfiguration() method allows projects to easily support different
> > names without breaking anything.
> >
> > The default behavior has not changed in the least.
>
> I don't think you see my point. Avalon/Framework is not meant to provide all
> implementations of these sorts of things. What you proposed adding seems very
> application specific and limited in usefulness. Why can't Axis use their own
> method of constructing Parameters? That seems much more sensible to me.
Requiring other projects to either change their configuration schemes or
reimplement ( extend or whatever ) parameters objects simply so they can
change what they call a parameter is kind of rediculous.
Adding the ability to identify the attribute names is FS (flexibility syndrome).
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:
> > I am fairly sure I don't like this. If parts are read-only and parts are
> > read-write then IMHO they should not be part of same Parameters object. A
> > possible solution to get around this would be to allow Parameters to have
> > a parent and make it possible to specify who to read properties from
> > first. (This would mean that properties were always accessed from parent
> > first and then from child or vice versa). So you would have something
> > like
> >
> > Parameters parent = new Parameters();
> > ...setup immutable variables here...
> > parent.makeReadOnly();
> >
> > Parameters child1 = new Parameters( parent, false );
> > ...setup non "locked" parameters here...
> >
> > Then later on
> >
> > Parameters child2 = new Parameters( parent, false );
> > child2.merge( child 1 );
> > ...setup non "locked" parameters here for second time...
> >
> > Actually this is what I partially do in quite a few of my apps. But I do
> > it manually and instead of using term parent I use term defaults ;)
>
> There are three issues with your approach:
>
> 1) If the parent is accessed first, then you can never change the value of
> a parameter. Parameters will always return the value of the parent.
You mean the parents values are immutable/locked. Isn't that what you wanted?
> 2) If the child is accessed first, then you can override a "locked" value.
right. Which is why you would specify that parent is accessed first when you
wanted it to be accessed first?
> 3) When deriving your Parameters object from a Configuration object set,
> you cannot determine which are meant to be locked, and which are allowed to
> be changed. Instead you are forced to have the parameters specified in two
> locations. This makes automatic incorporation in Excalibur's
> ComponentManager near impossible.
Right. But fundamentally I don't think we should be supporting partial
mutability in any sort of configuration data. We don't have partially mutable
Config trees and I don't think we should support it.
> > > and a "fromConfiguration"
> > > method that allows you to specify the element name for a parameter.
> > > The attributes would be the same, but a project would be able to
> > > use the name "option" instead of "parameter" if it wanted to.
> >
> > Seems kinda ugly to me.
>
> If you have a better way of implementing the same thing let me know. The
> thing is that we are forcing all configuration schemes to be the same. The
> new fromConfiguration() method allows projects to easily support different
> names without breaking anything.
>
> The default behavior has not changed in the least.
I don't think you see my point. Avalon/Framework is not meant to provide all
implementations of these sorts of things. What you proposed adding seems very
application specific and limited in usefulness. Why can't Axis use their own
method of constructing Parameters? That seems much more sensible to me.
If it is absolutely essential that these features are present using the
mechanisms you specified couldn't you just do something like
class AxisParameters extends Parameters
{
fromConfiguration();
setProperty( key, value, isLocked );
}
--
Cheers,
Pete
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Tue, 25 Sep 2001 23:40, Berin Loritsch wrote:
> > Axis has a consept for options (equivalent to our parameters)
> > that our existing Parameters object does not satisfy. It is
> > the concept of "locked" parameters.
> >
> > The approach is in between the two states our Parameters object
> > can handle. Currently we have completely modifiable or read only.
> > The change would allow the markup to be changed to:
> >
> > <parameter name="foo" value="bar" locked="true"/>
> > <parameter name="baz" value="vip"/>
> >
> > The additional parameter (if present) will lock a parameter no
> > matter what state the object is in.
> >
> > That way, a run-time system can have parameters that are modified
> > at specific times--but keep certain params from changing during
> > the life of the system.
>
> I am fairly sure I don't like this. If parts are read-only and parts are
> read-write then IMHO they should not be part of same Parameters object. A
> possible solution to get around this would be to allow Parameters to have a
> parent and make it possible to specify who to read properties from first.
> (This would mean that properties were always accessed from parent first and
> then from child or vice versa). So you would have something like
>
> Parameters parent = new Parameters();
> ...setup immutable variables here...
> parent.makeReadOnly();
>
> Parameters child1 = new Parameters( parent, false );
> ...setup non "locked" parameters here...
>
> Then later on
>
> Parameters child2 = new Parameters( parent, false );
> child2.merge( child 1 );
> ...setup non "locked" parameters here for second time...
>
> Actually this is what I partially do in quite a few of my apps. But I do it
> manually and instead of using term parent I use term defaults ;)
There are three issues with your approach:
1) If the parent is accessed first, then you can never change the value of
a parameter. Parameters will always return the value of the parent.
2) If the child is accessed first, then you can override a "locked" value.
3) When deriving your Parameters object from a Configuration object set, you
cannot determine which are meant to be locked, and which are allowed to be
changed. Instead you are forced to have the parameters specified in two
locations. This makes automatic incorporation in Excalibur's ComponentManager
near impossible.
The hierarchical Parameters approach would be useful when we are adding new
sets of Parameters that are accessible to children. It does not address management
of Parameterizable objects where a system is designed to change during its
lifetime.
>
> > and a "fromConfiguration"
> > method that allows you to specify the element name for a parameter.
> > The attributes would be the same, but a project would be able to
> > use the name "option" instead of "parameter" if it wanted to.
>
> Seems kinda ugly to me.
If you have a better way of implementing the same thing let me know. The thing
is that we are forcing all configuration schemes to be the same. The new
fromConfiguration() method allows projects to easily support different names
without breaking anything.
The default behavior has not changed in the least.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Peter Donald <do...@apache.org>.
On Tue, 25 Sep 2001 23:40, Berin Loritsch wrote:
> Axis has a consept for options (equivalent to our parameters)
> that our existing Parameters object does not satisfy. It is
> the concept of "locked" parameters.
>
> The approach is in between the two states our Parameters object
> can handle. Currently we have completely modifiable or read only.
> The change would allow the markup to be changed to:
>
> <parameter name="foo" value="bar" locked="true"/>
> <parameter name="baz" value="vip"/>
>
> The additional parameter (if present) will lock a parameter no
> matter what state the object is in.
>
> That way, a run-time system can have parameters that are modified
> at specific times--but keep certain params from changing during
> the life of the system.
I am fairly sure I don't like this. If parts are read-only and parts are
read-write then IMHO they should not be part of same Parameters object. A
possible solution to get around this would be to allow Parameters to have a
parent and make it possible to specify who to read properties from first.
(This would mean that properties were always accessed from parent first and
then from child or vice versa). So you would have something like
Parameters parent = new Parameters();
...setup immutable variables here...
parent.makeReadOnly();
Parameters child1 = new Parameters( parent, false );
...setup non "locked" parameters here...
Then later on
Parameters child2 = new Parameters( parent, false );
child2.merge( child 1 );
...setup non "locked" parameters here for second time...
Actually this is what I partially do in quite a few of my apps. But I do it
manually and instead of using term parent I use term defaults ;)
> There are two other things I would like to see: A Reparameterizable
> interface (to compliment Reconfigurable),
+1
> and a "fromConfiguration"
> method that allows you to specify the element name for a parameter.
> The attributes would be the same, but a project would be able to
> use the name "option" instead of "parameter" if it wanted to.
Seems kinda ugly to me.
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 01:01, Berin Loritsch wrote:
> Berin Loritsch wrote:
> > Here is a diff that allows us to do what I was talking about:
>
> I fixed the diff, and augmented the TestCase to make sure it was working
> properly.
>
> If there are no objections I will commit it today. It is fully backward
> compatible, and simply provides new functionality (oh, and the
> fromProperties should be quicker!).
I am fairly sure I don't like it ... though you may be able to change my mind
;)
--
Cheers,
Pete
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Here is a diff that allows us to do what I was talking about:
I fixed the diff, and augmented the TestCase to make sure it was working
properly.
If there are no objections I will commit it today. It is fully backward
compatible, and simply provides new functionality (oh, and the fromProperties
should be quicker!).
>
> Index: Parameters.java
> ===================================================================
> RCS file: /home/cvs/jakarta-avalon/src/java/org/apache/avalon/framework/parameters/Parameters.java,v
> retrieving revision 1.8
> diff -w -r1.8 Parameters.java
> 31a32
> > private HashMap m_locks = new HashMap();
> 40a42
> > * @deprecated Use the <code>setParameter</code> method with three options.
> 43a46,57
> > return this.setParameter(name, value, false);
> > }
> >
> > /**
> > * Set the <code>String</code> value of a specified parameter.
> > * <p />
> > * If the specified value is <b>null</b> the parameter is removed.
> > *
> > * @return The previous value of the parameter or <b>null</b>.
> > */
> > public String setParameter( final String name, final String value, final boolean isLocked )
> > {
> 52a67,74
> > if (Boolean.TRUE.equals((Boolean) m_locks.get(name)))
> > {
> > return null;
> > }
> >
> > synchronized(this)
> > {
> > m_locks.remove(name);
> 54a77
> > }
> 55a79,81
> > synchronized(this)
> > {
> > m_locks.put(name, new Boolean(isLocked));
> 57a84,92
> > }
> >
> > /**
> > * Remove a parameter from the parameters object
> > */
> > public void removeParameter( final String name )
> > {
> > this.setParameter(name, null, false);
> > }
> 60c95
> < * Return an <code>Enumeration</code> view of all parameter names.
> ---
> > * Return an <code>Iterator</code> view of all parameter names.
> 418c453,456
> < * object.
> ---
> > * object. This acts exactly like the following method call:
> > * <pre>
> > * Parameters.fromConfiguration(configuration, "parameter");
> > * </pre>
> 425a464,477
> > return Parameters.fromConfiguration(configuration, "parameter");
> > }
> >
> > /**
> > * Create a <code>Parameters</code> object from a <code>Configuration</code>
> > * object using the supplied element name.
> > *
> > * @param configuration the Configuration
> > * @param elementName the element name for the parameters
> > * @return This <code>Parameters</code> instance.
> > */
> > public static Parameters fromConfiguration( final Configuration configuration, final String elementName )
> > throws ConfigurationException
> > {
> 432c484
> < final Configuration[] parameters = configuration.getChildren( "parameter" );
> ---
> > final Configuration[] parameters = configuration.getChildren( elementName );
> 441c493,494
> < param.setParameter( name, value );
> ---
> > final boolean isLocked = parameters[ i ].getAttributeAsBoolean( "locked", false );
> > param.setParameter( name, value, isLocked );
>
> Berin Loritsch wrote:
> >
> > Axis has a consept for options (equivalent to our parameters)
> > that our existing Parameters object does not satisfy. It is
> > the concept of "locked" parameters.
> >
> > The approach is in between the two states our Parameters object
> > can handle. Currently we have completely modifiable or read only.
> > The change would allow the markup to be changed to:
> >
> > <parameter name="foo" value="bar" locked="true"/>
> > <parameter name="baz" value="vip"/>
> >
> > The additional parameter (if present) will lock a parameter no
> > matter what state the object is in.
> >
> > That way, a run-time system can have parameters that are modified
> > at specific times--but keep certain params from changing during
> > the life of the system.
> >
> > There are two other things I would like to see: A Reparameterizable
> > interface (to compliment Reconfigurable), and a "fromConfiguration"
> > method that allows you to specify the element name for a parameter.
> > The attributes would be the same, but a project would be able to
> > use the name "option" instead of "parameter" if it wanted to.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed change to Parameters:
Posted by Berin Loritsch <bl...@apache.org>.
Here is a diff that allows us to do what I was talking about:
Index: Parameters.java
===================================================================
RCS file: /home/cvs/jakarta-avalon/src/java/org/apache/avalon/framework/parameters/Parameters.java,v
retrieving revision 1.8
diff -w -r1.8 Parameters.java
31a32
> private HashMap m_locks = new HashMap();
40a42
> * @deprecated Use the <code>setParameter</code> method with three options.
43a46,57
> return this.setParameter(name, value, false);
> }
>
> /**
> * Set the <code>String</code> value of a specified parameter.
> * <p />
> * If the specified value is <b>null</b> the parameter is removed.
> *
> * @return The previous value of the parameter or <b>null</b>.
> */
> public String setParameter( final String name, final String value, final boolean isLocked )
> {
52a67,74
> if (Boolean.TRUE.equals((Boolean) m_locks.get(name)))
> {
> return null;
> }
>
> synchronized(this)
> {
> m_locks.remove(name);
54a77
> }
55a79,81
> synchronized(this)
> {
> m_locks.put(name, new Boolean(isLocked));
57a84,92
> }
>
> /**
> * Remove a parameter from the parameters object
> */
> public void removeParameter( final String name )
> {
> this.setParameter(name, null, false);
> }
60c95
< * Return an <code>Enumeration</code> view of all parameter names.
---
> * Return an <code>Iterator</code> view of all parameter names.
418c453,456
< * object.
---
> * object. This acts exactly like the following method call:
> * <pre>
> * Parameters.fromConfiguration(configuration, "parameter");
> * </pre>
425a464,477
> return Parameters.fromConfiguration(configuration, "parameter");
> }
>
> /**
> * Create a <code>Parameters</code> object from a <code>Configuration</code>
> * object using the supplied element name.
> *
> * @param configuration the Configuration
> * @param elementName the element name for the parameters
> * @return This <code>Parameters</code> instance.
> */
> public static Parameters fromConfiguration( final Configuration configuration, final String elementName )
> throws ConfigurationException
> {
432c484
< final Configuration[] parameters = configuration.getChildren( "parameter" );
---
> final Configuration[] parameters = configuration.getChildren( elementName );
441c493,494
< param.setParameter( name, value );
---
> final boolean isLocked = parameters[ i ].getAttributeAsBoolean( "locked", false );
> param.setParameter( name, value, isLocked );
Berin Loritsch wrote:
>
> Axis has a consept for options (equivalent to our parameters)
> that our existing Parameters object does not satisfy. It is
> the concept of "locked" parameters.
>
> The approach is in between the two states our Parameters object
> can handle. Currently we have completely modifiable or read only.
> The change would allow the markup to be changed to:
>
> <parameter name="foo" value="bar" locked="true"/>
> <parameter name="baz" value="vip"/>
>
> The additional parameter (if present) will lock a parameter no
> matter what state the object is in.
>
> That way, a run-time system can have parameters that are modified
> at specific times--but keep certain params from changing during
> the life of the system.
>
> There are two other things I would like to see: A Reparameterizable
> interface (to compliment Reconfigurable), and a "fromConfiguration"
> method that allows you to specify the element name for a parameter.
> The attributes would be the same, but a project would be able to
> use the name "option" instead of "parameter" if it wanted to.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org