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 2002/06/15 17:01:12 UTC
[A5] Parameters Package
I see nothing wrong about the Parameters package as a general rule, just
a
couple questions:
1) Do we want to decouple the Parameters interface from the Parameters
object
like we do with Configuration?
2) Are we going to explicitly declare Parameterizable and Configurable
as
mutually exclusive?
As to #1, it would provide consistency and provide a nice way of making
different implementations of the parameters object. It would also
encourage
us to place the Parameters.fromProperties() and
Parameters.fromConfiguration()
methods into a ParameterUtils class.
I am +1.
As to #2, I believe that is what we intended to do in the first place.
The
problem is that there is no way to programatically enforce it without
the
ContainerUtils or some other helper class. If it is mutually exclusive,
we have to specify that in the javadocs--and say that if a component
extends
both Configurable and Parameterizable the result is undefined.
Something like the text below:
"WARNING: The Parameterizable interface is mutually exclusive of the
Configurable interface. If your component extends both of those
interfaces, the behavior is undefined. The container is free to throw
an exception and refuse to use your component, or to pass an object
in to both methods. The object may be empty. In short do not mix
these two interfaces in your components."
Any other concerns?
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Leo Simons <le...@apache.org>.
> Could you please post some examples?
will do tonight.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>>As to #2, I believe that is what we intended to do in the
>>
>>first place.
>>
>>-1. Please provide some arguments (again, yup). They are in
>>use together in my code (it's convenient)
Could you please post some examples?
I thought the same before, but looking at my code, I found out that it
was used only once, and was not really *that* convenient.
IMHO, doing a Parameters myparams = MyConfiguration.getParameters()
could simple be the answer.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] Parameters Package
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-06-17 at 15:45, Berin Loritsch wrote:
> > From: Leo Simons [mailto:leosimons@apache.org]
> > > As to #2, I believe that is what we intended to do in the
> > first place.
> >
> > -1. Please provide some arguments (again, yup). They are in
> > use together in my code (it's convenient), and probably in
> > other places as well. I don't see a design reason they should
> > be exclusive, and lots of problems.
>
>
> Maintenance, maintenance, maintenance.
>
> It is easier to look in one place to see what gets set where,
> as opposed to multiple locations.
yup.
> The poor souls that inherit your systems have to question
> what gets set where, when, and how that information gets populated.
nah...there's documentation for that =)
still...
I've looked in a few places where I use both configuration and
parameters. Everywhere, it is possible to merge the configuration and
the parameters.
Providing a utility that does exactly that:
A5Configuration MigrationUtils.merge(
A4Configuration, A4Parameters );
would be cool, where all gaps in between the Configuration and
Parameters APIs are filled in the new A5Configuration. Wonder whether
that affects the A5Configuration interface...
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] Parameters Package
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
> > As to #2, I believe that is what we intended to do in the
> first place.
>
> -1. Please provide some arguments (again, yup). They are in
> use together in my code (it's convenient), and probably in
> other places as well. I don't see a design reason they should
> be exclusive, and lots of problems.
Maintenance, maintenance, maintenance.
It is easier to look in one place to see what gets set where,
as opposed to multiple locations.
The poor souls that inherit your systems have to question
what gets set where, when, and how that information gets populated.
Keep in mind that ECM/Fortress do it differently than Merlin.
It needs to be unified for maintainers of avalon systems.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Leo Simons <le...@apache.org>.
> 1) Do we want to decouple the Parameters interface from the Parameters
> object
> like we do with Configuration?
>
> As to #1, it would provide consistency and provide a nice way of making
> different implementations of the parameters object.
why would you need different implementations?
Beware of flexibility syndrome.
> It would also
> encourage
> us to place the Parameters.fromProperties() and
> Parameters.fromConfiguration()
> methods into a ParameterUtils class.
we can do that anyway =)
-0 till I see a valid use case.
> 2) Are we going to explicitly declare Parameterizable and Configurable
> as
> mutually exclusive?
>
>
> I am +1.
>
> As to #2, I believe that is what we intended to do in the first place.
-1. Please provide some arguments (again, yup). They are in use together
in my code (it's convenient), and probably in other places as well. I
don't see a design reason they should be exclusive, and lots of
problems.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Peter Royal <pr...@apache.org>.
On Saturday 15 June 2002 11:36 am, Berin Loritsch wrote:
> > I'm against making them mutually exclusive:
> >
> > - users use them together
>
> The common implementation between Parameterizable and Configurable
> is this:
>
> component.configure( config );
> component.parameterize( Parameters.fromConfiguration( config ) );
>
> What's the big deal about doing that in your configuration
> method?
I also see no reason for them to be mutually exclusive. Yes, some containers
may not support both methods simultaneously, but others do.
Phoenix kernel components can support both. The Parameters passed are things
from the runtime environment while the Configuration is from the kernel
configuration document.
Yes, as a general rule having both will not happen very often, but we need to
keep the corner cases in consideration.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>
>>There is no reason why having both is bad.
>
>
> Question: what is the difference supposed to be between Parameters and
> Configurations?
>
> Last time I was subscribed to this list, we had configurations and they
> were immutable.
>
> So, my wild guess would be that you needed something mutable and added
> parameters.
>
> But then, this is overlapping with a Context.
>
> I have the impression that before trying to patch such abstract API we
> should agree on *WHAT THE HELL THEY ARE SUPPOSED TO DO FOR YOU*.
>
> Do I make any sense?
You're a bit behind on answers ;-) I have already expressed the feeling
that Configurations and Parameters are different views of the same
concept of component configuration.
Hence I propose to have a single Configuration system and make
Parameters just a view on hierarchical configs.
@see my last mail on this
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Leo Simons <le...@apache.org>.
> Question: what is the difference supposed to be between Parameters and
> Configurations?
Configuration is hierarchical, parameters is a simple string-based map
that can contain only strings. I basically added the parameters stuff
because it easier to use.
> Last time I was subscribed to this list, we had configurations and they
> were immutable.
>
> So, my wild guess would be that you needed something mutable and added
> parameters.
nope. Anything passed to a component during initialization should be
immutable. A component cannot modify its own parameters, context,
configuration. That's subversion of control.
> But then, this is overlapping with a Context.
>
> I have the impression that before trying to patch such abstract API we
> should agree on *WHAT THE HELL THEY ARE SUPPOSED TO DO FOR YOU*.
>
> Do I make any sense?
your thoughts are valid, but I think we already know what parameters is:
1-d string based lookup of strings, which is very convenient and simple.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> There is no reason why having both is bad.
Question: what is the difference supposed to be between Parameters and
Configurations?
Last time I was subscribed to this list, we had configurations and they
were immutable.
So, my wild guess would be that you needed something mutable and added
parameters.
But then, this is overlapping with a Context.
I have the impression that before trying to patch such abstract API we
should agree on *WHAT THE HELL THEY ARE SUPPOSED TO DO FOR YOU*.
Do I make any sense?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>>I see nothing wrong about the Parameters package as a general rule,
>>>just a couple questions:
>>>
>>>1) Do we want to decouple the Parameters interface from the
>>
>>Parameters
>>
>>>object
>>> like we do with Configuration?
>>>
>>>2) Are we going to explicitly declare Parameterizable and
>>
>>Configurable
>>
>>>as
>>> mutually exclusive?
>>>
>>>As to #1, it would provide consistency and provide a nice way of
>>>making different implementations of the parameters object.
>>
>>It would
>>
>>>also encourage us to place the Parameters.fromProperties() and
>>>Parameters.fromConfiguration()
>>>methods into a ParameterUtils class.
>>
>>+0, but we must keep some compatibility with the past.
>
>
> I am not proposing we change the interface completely, but move the
> static methods to another utility class.
>
> The compatibility layer will hide these changes from existing systems.
> The framework-compat.jar should provide binary compatibility as much
> as possible. This is one case we can guarantee it--and provide a
> cleaner
> design at the same time.
+1 I was +0 because it sounded good, but now I also see it in practice :-)
>>I'm against making them mutually exclusive:
>>
>>- users use them together
>
>
> The common implementation between Parameterizable and Configurable
> is this:
>
> component.configure( config );
> component.parameterize( Parameters.fromConfiguration( config ) );
>
> What's the big deal about doing that in your configuration
> method?
I don't do it this way.
This is how Cocoon does it AFAIK, take off your Cocoon hat ;-)
>>- there is no reason why they have to be mutually exclusive
>
>
> There is no reason why the shouldn't be....
;-)
In this case, the most lazziefaire wins (not exclusive).
Every imposition you put is something to check for, ergo more complexity.
If it's not that important, let's not enforce it.
>>- there is no way to enforce it
>
> There is through helper classes. Those classes would be available
> in framework for containers to use to validate the lifecycle.
See above.
>>- there is no way to make users easily understand this
>
>
> You're the kind of person who throws the directions away before
> you start to put a bike together aren't you? ;P
Directions?
What directions?
> Sure there is--but it has to be clearly stated in the javadocs,
> and in any exceptions or log messages thrown by the container.
Naaa, good systems must be self-commenting and self-enforcing.
Easy does it.
>>I use Configuration for general config, and Parameters for
>>per-instance
>>config, even in the same class, and find it usefull.
>
>
> In avalon framework there is no distinction between general and
> per-instance configuration. Each instance of the component is
> fed the same configuration object or parameters obect.
The fact that there is no distinction is good.
Gives more flexibility, makes no harm.
> Also the parameters object is derived from the configuration object
Not here, that's a Cocoon implementation detail.
> that would otherwise be passed into the component. Really, it is
> pretty messy to mix those two.
Still don't see why.
One thing is *recommending* to use one or the other.
Another is *enforcing* it.
There is no reason why having both is bad.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> > - there is no reason why they have to be mutually exclusive
>
> There is no reason why the shouldn't be....
Berin,
I think it would be better for anybody if you understood that the fact
that somebody is already using something *IS* a good reason why it
shouldn't be changed without good reasons.
The "ivory tower" anti-pattern rules on this list... I see very bad
times ahead :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] Parameters Package
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Berin Loritsch wrote:
> > I see nothing wrong about the Parameters package as a general rule,
> > just a couple questions:
> >
> > 1) Do we want to decouple the Parameters interface from the
> Parameters
> > object
> > like we do with Configuration?
> >
> > 2) Are we going to explicitly declare Parameterizable and
> Configurable
> > as
> > mutually exclusive?
> >
> > As to #1, it would provide consistency and provide a nice way of
> > making different implementations of the parameters object.
> It would
> > also encourage us to place the Parameters.fromProperties() and
> > Parameters.fromConfiguration()
> > methods into a ParameterUtils class.
>
> +0, but we must keep some compatibility with the past.
I am not proposing we change the interface completely, but move the
static methods to another utility class.
The compatibility layer will hide these changes from existing systems.
The framework-compat.jar should provide binary compatibility as much
as possible. This is one case we can guarantee it--and provide a
cleaner
design at the same time.
> I'm against making them mutually exclusive:
>
> - users use them together
The common implementation between Parameterizable and Configurable
is this:
component.configure( config );
component.parameterize( Parameters.fromConfiguration( config ) );
What's the big deal about doing that in your configuration
method?
> - there is no reason why they have to be mutually exclusive
There is no reason why the shouldn't be....
> - there is no way to enforce it
There is through helper classes. Those classes would be available
in framework for containers to use to validate the lifecycle.
> - there is no way to make users easily understand this
You're the kind of person who throws the directions away before
you start to put a bike together aren't you? ;P
Sure there is--but it has to be clearly stated in the javadocs,
and in any exceptions or log messages thrown by the container.
> I use Configuration for general config, and Parameters for
> per-instance
> config, even in the same class, and find it usefull.
In avalon framework there is no distinction between general and
per-instance configuration. Each instance of the component is
fed the same configuration object or parameters obect.
Also the parameters object is derived from the configuration object
that would otherwise be passed into the component. Really, it is
pretty messy to mix those two.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> I see nothing wrong about the Parameters package as a general rule, just
> a
> couple questions:
>
> 1) Do we want to decouple the Parameters interface from the Parameters
> object
> like we do with Configuration?
>
> 2) Are we going to explicitly declare Parameterizable and Configurable
> as
> mutually exclusive?
>
> As to #1, it would provide consistency and provide a nice way of making
> different implementations of the parameters object. It would also
> encourage
> us to place the Parameters.fromProperties() and
> Parameters.fromConfiguration()
> methods into a ParameterUtils class.
+0, but we must keep some compatibility with the past.
> I am +1.
>
> As to #2, I believe that is what we intended to do in the first place.
> The
> problem is that there is no way to programatically enforce it without
> the
> ContainerUtils or some other helper class. If it is mutually exclusive,
> we have to specify that in the javadocs--and say that if a component
> extends
> both Configurable and Parameterizable the result is undefined.
>
> Something like the text below:
>
> "WARNING: The Parameterizable interface is mutually exclusive of the
> Configurable interface. If your component extends both of those
> interfaces, the behavior is undefined. The container is free to throw
> an exception and refuse to use your component, or to pass an object
> in to both methods. The object may be empty. In short do not mix
> these two interfaces in your components."
I'm against making them mutually exclusive:
- users use them together
- there is no reason why they have to be mutually exclusive
- there is no way to enforce it
- there is no way to make users easily understand this
I use Configuration for general config, and Parameters for per-instance
config, even in the same class, and find it usefull.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Stephen McConnell <mc...@osm.net>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> I see nothing wrong about the Parameters package as a general rule, just
>> a
>> couple questions:
>>
>> 1) Do we want to decouple the Parameters interface from the Parameters
>> object
>> like we do with Configuration?
>
>
> Advantage - alternative implementations.
> Disadvantage - implemetation change on Parameters instance creation.
> The advantage is nice in principal but does is justify a change that
> will impact existing code. Based on the projects I'm aware of - the
> change would be very minor.
> +0.5
>
>>
>> 2) Are we going to explicitly declare Parameterizable and Configurable
>> as mutually exclusive?
>
>
> Minor correction in terminology.
> Parameterizable and Configurable are currently declared as mutually
> exclusive. Tghe question is, "are we going to enforce this", "relax
> this", or "ignore this"?
>
>> As to #1, it would provide consistency and provide a nice way of making
>> different implementations of the parameters object. It would also
>> encourage us to place the Parameters.fromProperties() and
>> Parameters.fromConfiguration() methods into a ParameterUtils class.
>>
>> I am +1.
>
>
> I'm leaning in that direction.
>
>
>> As to #2, I believe that is what we intended to do in the first place.
>> The problem is that there is no way to programatically enforce it
>> without the ContainerUtils or some other helper class. If it is
>> mutually exclusive, we have to specify that in the javadocs --and say
>> that if a component extends Configurable and Parameterizable the
>> result is undefined.
>
>
> +1
>
>> Something like the text below:
>>
>> "WARNING: The Parameterizable interface is mutually exclusive of the
>> Configurable interface. If your component extends both of those
>> interfaces, the behavior is undefined.
>
>
> That is sufficient.
>
>> The container is free to throw
>> an exception and refuse to use your component, or to pass an object
>> in to both methods. The object may be empty. In short do not mix
>> these two interfaces in your components."
>
>
> Above detail is going into too much detail (suggesting what may happen).
> Declaring that the behavior is "undefined" is sufficient.
>
> The question of a common approach to handling this situation by
> containers would be desirable. I'm differentiating here between generic
> contains and custom contains. Custom contains should be able to mix and
> match both because the custom container knows more about the components
> it is managing. However, generic contains (Phoenix/Merlin/ECm/Fortres)
> should attempt to take uniform approach. Possibilities include:
>
> 1. reject the component at validation stage (nasty)
> 2. apply configuration and bypass parameterization (preferred)
> 3. apply parameterization and bypass configuration
> 4. apply both (inconsitent unless we have a consitent approach to
> identifying a parameter description (XML) from a configuration).
>
Or, in the case of a mixed case, the parameter object could come from
<classname>.properties - which would be a workable solution in that it
would eliminate the issues of paramters derived from configuration info.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] Parameters Package
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Berin Loritsch wrote:
> > I see nothing wrong about the Parameters package as a general rule,
> > just a couple questions:
> >
> > 1) Do we want to decouple the Parameters interface from the
> Parameters
> > object
> > like we do with Configuration?
>
> Advantage - alternative implementations.
> Disadvantage - implemetation change on Parameters instance
> creation. The advantage is nice in principal but does is
> justify a change that
> will impact existing code. Based on the projects I'm aware of - the
> change would be very minor.
> +0.5
The compatibility jar would take care of the incompatibility for
legacy apps. Nothing needs to be done at this stage.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Parameters Package
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
> I see nothing wrong about the Parameters package as a general rule, just
> a
> couple questions:
>
> 1) Do we want to decouple the Parameters interface from the Parameters
> object
> like we do with Configuration?
Advantage - alternative implementations.
Disadvantage - implemetation change on Parameters instance creation.
The advantage is nice in principal but does is justify a change that
will impact existing code. Based on the projects I'm aware of - the
change would be very minor.
+0.5
>
> 2) Are we going to explicitly declare Parameterizable and Configurable
> as mutually exclusive?
Minor correction in terminology.
Parameterizable and Configurable are currently declared as mutually
exclusive. Tghe question is, "are we going to enforce this", "relax
this", or "ignore this"?
> As to #1, it would provide consistency and provide a nice way of making
> different implementations of the parameters object. It would also
> encourage us to place the Parameters.fromProperties() and
> Parameters.fromConfiguration() methods into a ParameterUtils class.
>
> I am +1.
I'm leaning in that direction.
> As to #2, I believe that is what we intended to do in the first place.
> The problem is that there is no way to programatically enforce it
> without the ContainerUtils or some other helper class. If it is
> mutually exclusive, we have to specify that in the javadocs --and say
> that if a component extends Configurable and Parameterizable the
> result is undefined.
+1
> Something like the text below:
>
> "WARNING: The Parameterizable interface is mutually exclusive of the
> Configurable interface. If your component extends both of those
> interfaces, the behavior is undefined.
That is sufficient.
> The container is free to throw
> an exception and refuse to use your component, or to pass an object
> in to both methods. The object may be empty. In short do not mix
> these two interfaces in your components."
Above detail is going into too much detail (suggesting what may happen).
Declaring that the behavior is "undefined" is sufficient.
The question of a common approach to handling this situation by
containers would be desirable. I'm differentiating here between generic
contains and custom contains. Custom contains should be able to mix and
match both because the custom container knows more about the components
it is managing. However, generic contains (Phoenix/Merlin/ECm/Fortres)
should attempt to take uniform approach. Possibilities include:
1. reject the component at validation stage (nasty)
2. apply configuration and bypass parameterization (preferred)
3. apply parameterization and bypass configuration
4. apply both (inconsitent unless we have a consitent approach to
identifying a parameter description (XML) from a configuration).
Steve.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>