You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2004/02/04 20:30:28 UTC
MutableConfiguration Proposal Summary
Woah.
I finally finished reading the MutableConfiguration thread(s). Leo is
right, Gump might be a TLP before this gets done! :) Anyway, here's my take
on a number of the issues presented:
Contents
1. Comments on the Proposal and Implementation Details
2. Original Proposal: MutableConfiguration
3. Concerns with MutableConfiguration Proposal
4. Tangents
5. Summary
1. Comments on the Proposal and Implementation Details
In Avalon, we love to discuss things to death. It's amazing how verbose
this community is. :) That's not necessarily bad, but it can be frustrating
at times. Leo's initial proposal was very simple but, not unexpectedly, got
caught up in use cases, implementation discussions, and other tangents. For
my sake at least I'll be trying to summarize the proposal and various ideas
on the table throughout this email.
2. Original Proposal: MutableConfiguration
Leo's original proposal (or clarification) is at:
http://marc.theaimsgroup.com/?l=avalon-dev&m=107485031403277&w=2
The interface is for Containers and other privileged extensions and not part
of any lifecycle interface or component contract. The fact that it could be
someday or that it brings up all sorts of related topics (see tangents
below) has spurred some healthy discussion. However, keeping to Leo's
original and simple idea, there are still a couple of concerns which need
resolved.
3. Concerns with MutableConfiguration Proposal
a) Where does it belong?
* avalon-api
* avalon-spi
* avalon-impl
I don't think avalon-api is a good idea. I don't like the idea of a one
class group (avalon-spi), but if we identify other interfaces which belong
there, then that's where it belongs. In the meantime, we can easily add
MutableConfiguration to avalon-impl now and then worry about defining
avalon-spi later.
Oh, and I think Stephen's issues with excalibur-configuration have merit,
but it's been too long since I looked at that package or thought about a
solution and I don't see that as essential to this proposal.
b) Should MutableConfiguration extend Configuration?
Yes?
* MutableConfiguration is a type of Configuration
* Existing code which uses Configuration could take advantage of
MutableConfiguration via casting (nice for containers)
No?
* Existing code which uses Configuration could take advantage of
MutableConfiguration via casting (bad for components)
* Are there other reasons?
This is the only thing holding me up from a +1. I would just like to better
see the options and consider the consequences.
As far as I can tell, these are the two main concerns with the proposal.
Yes, there are many other ways to do something like this, but Leo has
accurately pointed out a flaw in the current design and adding something
like MutableConfiguration to avalon-impl could be done without impacting ANY
code dependent on Configuration or DefaultConfiguration.
4. Tangents
This is where the proposal got off track. None of these issues need to be
tied to MutableConfiguration or the vote. They can and should be discussed
in separate threads, though I would suggest waiting until we get
MutableConfiguration worked out.
a) MutableConfiguration vs DynamicConfiguration
b) Configuration events and change notification (listeners)
c) Reconfigurable interface (defining and implementing)
d) Configuration persistence implementations
e) Excalibur-configuration
f) Plugging similar holes in Context and ServiceManager
g) some other ones I'm sure I missed...
5. Summary
To reiterate:
The proposal is simply to add a MutableConfiguration interface to the
framework which defines the methods already implemented by
DefaultConfiguration. This would allow containers and extensions (NOT
components) to work with an interface and not an implementation. This is a
Good Thing. The two outstanding concerns are (1) where to put it and (2)
should it extend Configuration. I think it should be put into avalon-impl
for now and then we can begin to think about an avalon-spi. As for
extending Configuration, I'm not exactly sure yet and I want to consider the
options.
It's good to be back. :)
J. Aaron Farr
SONY ELECTRONICS
DDP-CIM
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration Proposal Summary
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> OK people, let's try to wrap this one up - one way or
> another...
Yep - closing this overdue.
> Are there any other issues besides the ones listed
> by Aaron? That is:
>
> a) Where does it belong?
> b) Should MutableConfiguration extend
> Configuration?
Not here.
Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Re[2]: MutableConfiguration -- interface and semantics
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hi, Leo!
>
> AT> Three more issues.
> LSU> can we move *all* your issues to a future proposal?
> LSU> I've been trying for *two weeks* to get this proposal
> through, and
> LSU> I'm not really up for extending it.
>
> Two weeks is plainly horrible.
>
> Still got a gut feeling ...
>
> with DefaultConfiguration we did
>
> DefaultConfiguration parent = new DefaultConfiguration( ... );
> DefaultConfiguration child = new DefaultConfiguration( "child" );
> parent.addChild( child );
>
> see the catch?
>
> We need a *factory method* somewhere.
The MutableConfiguration interface has a getMutableChild method that
works
just like the getChild() method, except it will create *and add* a child
node.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: MutableConfiguration -- interface and semantics
Posted by Anton Tagunov <at...@list.ru>.
Hi, Leo!
AT> Three more issues.
LSU> can we move *all* your issues to a future proposal?
LSU> I've been trying for *two weeks* to get this proposal through, and
LSU> I'm not really up for extending it.
Two weeks is plainly horrible.
Still got a gut feeling ...
with DefaultConfiguration we did
DefaultConfiguration parent = new DefaultConfiguration( ... );
DefaultConfiguration child = new DefaultConfiguration( "child" );
parent.addChild( child );
see the catch?
We need a *factory method* somewhere.
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration -- interface and semantics
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hi, gang!
>
> LSU> Are there any other issues besides the ones listed
> LSU> by Aaron? That is:
> LSU>
> LSU> a) Where does it belong?
> LSU> b) Should MutableConfiguration extend
> LSU> Configuration?
>
> Yes. Three more issues.
Anton,
can we move *all* your issues to a future proposal?
I've been trying for *two weeks* to get this proposal through, and
I'm not really up for extending it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
MutableConfiguration -- interface and semantics
Posted by Anton Tagunov <at...@list.ru>.
Hi, gang!
LSU> Are there any other issues besides the ones listed
LSU> by Aaron? That is:
LSU>
LSU> a) Where does it belong?
LSU> b) Should MutableConfiguration extend
LSU> Configuration?
Yes. Three more issues.
A.
addChild( Configuration other )
addAll( Configuration other )
addAllChildren( Configuration other )
should receive deep-copy semantics (unlike DefaultConfiguration)
B.
interface MutableConfiguration
{
/**
* Create a MutableConfiguration instance
* of the appropriate class and put to the
* list of children
*/
MutableConfiguration createChild( String name );
}
C.
Do we have
getChildCount()
getChild( int no )
getChild( String name )
methods in Configuration?
If no, I will ask to add them.
And likewise in MutableConfiguration I'd like
interface MutableConfiguration
{
MutableConfiguration getMutableChild( int no );
MutableConfiguration getMutableChild( String name );
}
or
interface ConfigurationMutator
{
int getChildCount();
ConfigurationMutator getChild( int no );
ConfigurationMutator getChild( String name );
}
I just have an aneasy feeling about methods returning arrays -
feel sorry about arrays being allocated. I'm not against these
methods, just want methods for accessing children one-by-one
also.
Cheers, Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration Proposal Summary
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
avalon-framework-api is out. Vote will be between -spi and -impl.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> > Then, you can pass in the DefaultImmutableConfiguration to any
client
> > that expects to hold on to a reference for ever and ever, and you
can
> > just pass your regular MutableConfiguration to the methods that just
> > require the configuration not to change at all.
>
> I've parsed the above sentence multiple times and I'm still
> in trying to figure out what this means.
OK, trying to clarify the above (I get some parsing errors as well):
The question is this: Given that you have a DefaultConfiguration and a
client
that expects a Configuration, when should you create a
DefaultImmutableConfiguration from your DefaultConfiguration and pass
it, and
when can you just pass your existing DefaultConfiguration?
My answer to that is:
Create a DefaultImmutableConfiguration when the client will hold on to
the reference you pass in. (Or when you don't trust the client.)
Pass your existing DefaultConfiguration when the client will not hold
on to the reference and when you trust it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration Proposal Summary
Posted by Stephen McConnell <mc...@apache.org>.
Hi Leo:
This is shaping up into something nicely.
More notes in-line.
Leo Sutic wrote:
>
>> a) Where does it belong?
>
>
> Can we solve this by a simple majority vote?
Sure.
> 1. avalon-framework-api
> 2. avalon-framework-spi
> 3. avalon-framework-impl
Just a small note - the avalon-framework-api option is not an option due
to the standing veto and should not be included in the vote - aside from
that it looks good.
> Everyone casts a vote for any repo where they want it.
> (Mutliple choices allowed.) Then we take the one
> with the most votes and just go with it.
Yep.
> Not optimal for anyone, but I've read arguments
> for all three, and they have about equal weight in
> my mind.
>
>
>> b) Should MutableConfiguration extend
>> Configuration?
>
>
> Problem here being that a component may
> downcast from Configuration to MutableConfiguration.
> An upcast from MutableConfiguration to Configuration
> should be no problem - but...
>
> I read the javadocs for Configuration and it states
> that a Configuration is immutable. The question now
> is: for how long? Is the Configuration passed to the
> component immutable for the duration of the configure()
> call or for all time? If the component keeps a reference
> to the Configuration passed in, is the Configuration
> guaranteed not to change for as long as the component
> holds the reference?
My assumption is that the configuration is immutable from the time that
the configuration is exposed to the client via configure, up to the
point where either:
(a) the component is suspended
(b) the component is disposed
>
> We have to assume that component writers think so.
>
> Therefore, a MutableConfiguration isa Configuration in
> terms of methods implemented, but not in terms of
> immutability. However, for functions that only rely
> on the Configuration being immutable for the duration
> of the call, it can be. For example:
>
>
> public class MyUtils {
> public static void serialize (Configuration config) {
> ...
> }
> }
>
> In this case, the serialize method expects the configuration
> not to change while it is executing - but what you do with the
> configuration after you have called it, it doesn't care about.
>
> I propose the following: I'll code a class that is called
> DefaultImmutableConfiguration. It will only expose the Configuration
> interface, and it will look like this:
>
>
> public class DefaultImmutableConfiguration
> implements Configuration {
>
> DefaultImmutableConfiguration (Configuration config) { ... }
>
> }
>
> The constructor will do a deep copy of the supplied Configuration,
> thus ensuring that the instance is immutable.
Much better than the proxy approach!!
:-)
> Then, you can pass in the DefaultImmutableConfiguration to
> any client that expects to hold on to a reference for ever and ever,
> and you can just pass your regular MutableConfiguration to
> the methods that just require the configuration not to change
> at all.
I've parsed the above sentence multiple times and I'm still in trying to
figure out what this means.
> Note regarding the name: Yes, I know that we should have:
>
> class DefaultConfiguration implements Configuration
>
> and:
>
> class DefaultMutableConfiguration
> extends DefaultConfiguration
> implements MutableConfiguration
>
> and not the thing I proposed:
>
> class DefaultConfiguration implements MutableConfiguration
>
> class DefaultImmutableConfiguration implements Configuration
>
> But I can't do it the proper way due to backwards compat.
So in effect we have DefaultConfiguration which in practice is a
DefaultMutableConfiguration and we have a utility class
DefaultImmutableConfiguration which is a immutable copy. Sounds fine to me.
One thing that comes out of the is the pain associated with publication
of implementation classes. In the future I would like to see a general
practice of maintaining flexibility with respect to published
implementations - they should be able to change as we need to - whereas
api contracts should be the reference for backward compatibility concerns.
Cheers, Steve.
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration Proposal Summary -- optimize for memory
consumption? - typo
Posted by Stephen McConnell <mc...@apache.org>.
Anton Tagunov wrote:
> AT> It does not matter if it is -spi or -api.
> AT>
> AT> (I would choose -api, if I had a vote here,
> AT> but count it as non-binding, I've been away too long ;-)
>
> I haven't gone mad. Just a typo:
That's good news!
> I does not matter if it is -spi or -impl.
> I would choose -spi, but please count this as a non-binding
> vote, I've been away too long
.. and its good to see you back!
Cheers, Steve.
> Anton
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[5]: MutableConfiguration Proposal Summary -- optimize for memory consumption? - typo
Posted by Anton Tagunov <at...@list.ru>.
AT> It does not matter if it is -spi or -api.
AT>
AT> (I would choose -api, if I had a vote here,
AT> but count it as non-binding, I've been away too long ;-)
I haven't gone mad. Just a typo:
I does not matter if it is -spi or -impl.
I would choose -spi, but please count this as a non-binding
vote, I've been away too long
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[4]: MutableConfiguration Proposal Summary -- optimize for memory consumption?
Posted by Anton Tagunov <at...@list.ru>.
Hi, Leo!
AT> But why do we want it?
AT> MutableConfiguration impl is *only* about *storing* data.
AT> So, why abstract it?
AT> Only to allow different storage strategies.
AT> Right?
LSU> Not as much *allow* different storage strategies as to
LSU> not have to make the strategy explicit. It's splitting hairs,
LSU> but... "I don't want to swap out the storage strategy,
LSU> and I don't want to care about it."
LSU> So, I want MutableConfiguration not so much because
LSU> I want to write another implementation of it, but because
LSU> I don't want to use a concrete class in my code when
LSU> an interface will do.
LSU> Of course, this means that we *can* allow other implementations,
LSU> but this is not the primary reason for me.
We're in concensus: we're abstracting interface to *make other
implementations possible*. And all what these implementations
may differ is is *storage strategy*.
LSU> The deep-copy is done when you absolutely, positively
LSU> have to ensure that a configuration is immutable.
AT> Right. I like the approach. The class is useful.
AT> But should we really apply this patter *always*?
LSU> No. Use it when it makes sense.
AT> Should we engrave it in Avalon spi?
LSU> The class will go into -impl.
AT> Have there been any concerns on Merlin footprint?
LSU> Since Merlin has complete control over the configuration
LSU> objects, it will probably not even use the class. If a component
LSU> wants to mess up *its own* configuration, it is free to do so.
I see it a bit different. Internals of any contianer may
pass MutableConfiguration instances around a lot. This
happens if part A adds some of the configuration and then
part B alters it. I'm more after using it inside containers
not only inside components. It's a legitimate usage, isn't it?
It does not matter if it is -spi or -api.
(I would choose -api, if I had a vote here,
but count it as non-binding, I've been away too long ;-)
In any case container internals will start using it.
Some lifecycle extensions and such.
And therefore we should not *lock our lifecycle extendsion
and container utilities* into using the deep-copy strategy.
Should we?
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Re[2]: MutableConfiguration Proposal Summary -- optimize for memory consumption?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hi, Leo!
>
> Really like it to talk fast :)
>
> AT> * the main use case is to allow different storage
> AT> structures behind MutableConfiguration
> AT>
> AT> right?
>
> LSU> No. The purpose is to allow an application to code against an
> LSU> interface (MutableConfiguration) instead of against a concrete
> LSU> class (DefaultConfiguration).
>
> But why do we want it?
>
> MutableConfiguration impl is *only* about *storing* data.
> So, why abstract it?
> Only to allow different storage strategies.
>
> Right?
Not as much *allow* different storage strategies as to
not have to make the strategy explicit. It's splitting hairs,
but... "I don't want to swap out the storage strategy,
and I don't want to care about it."
So, I want MutableConfiguration not so much because
I want to write another implementation of it, but because
I don't want to use a concrete class in my code when
an interface will do.
Of course, this means that we *can* allow other implementations,
but this is not the primary reason for me.
> LSU> The deep-copy is done when you absolutely, positively
> LSU> have to ensure that a configuration is immutable.
>
> Right. I like the approach. The class is useful.
>
> But should we really apply this patter *always*?
No. Use it when it makes sense.
> Should we engrave it in Avalon spi?
The class will go into -impl.
> Have there been any concerns on Merlin footprint?
Since Merlin has complete control over the configuration
objects, it will probably not even use the class. If a component
wants to mess up *its own* configuration, it is free to do so.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: MutableConfiguration Proposal Summary -- optimize for memory consumption?
Posted by Anton Tagunov <at...@list.ru>.
Hi, Leo!
Really like it to talk fast :)
AT> * the main use case is to allow different storage
AT> structures behind MutableConfiguration
AT>
AT> right?
LSU> No. The purpose is to allow an application to code against an
LSU> interface (MutableConfiguration) instead of against a concrete
LSU> class (DefaultConfiguration).
But why do we want it?
MutableConfiguration impl is *only* about *storing* data.
So, why abstract it?
Only to allow different storage strategies.
Right?
LSU> The deep-copy is done when you absolutely, positively
LSU> have to ensure that a configuration is immutable.
Right. I like the approach. The class is useful.
But should we really apply this patter *always*?
Should we engrave it in Avalon spi?
Have there been any concerns on Merlin footprint?
Anton
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration Proposal Summary -- optimize for memory consumption?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hello, guys!
>
> Farr> b) Should MutableConfiguration extend
> Farr> Configuration?
>
> LSU> public class DefaultImmutableConfiguration
> LSU> implements Configuration
> LSU> {
> LSU> DefaultImmutableConfiguration (Configuration config)
> LSU> {
> LSU> ...
> LSU> }
> LSU> }
>
> LSU> The constructor will do a deep copy of the supplied
> Configuration,
> LSU> thus ensuring that the instance is immutable.
>
> The class looks usefull indeed.
> One reservation nevertheless:
>
> * the main use case is to allow different storage
> structures behind MutableConfiguration
>
> right?
No. The purpose is to allow an application to code against an
interface (MutableConfiguration) instead of against a concrete
class (DefaultConfiguration).
> * this is done to choose between
>
> - faster
> - low-memory-footprint
>
> implementations depending on evironment
> (desktop/server/Java2ME)
> and size of configuration provisioned
>
> right?
No.
> *IF* both answers are 'yes', then I'd prefer not to
> deep-copy the configuration data unless it's unavoidable
The deep-copy is done when you absolutely, positively
have to ensure that a configuration is immutable.
> If we want to conserve memory then I'd go about it like
> once the container has passed configuration to client
> that will hold on if for ever and ever, the container just
> stops modifying it.
That's fine as well. The container should do that. But:
The DefaultImmutableConfiguration is for when you
receive a Configuration, and *don't* have a guarantee that
you'll be able to hold on to it for as long as you'd like to.
Copying it to a DefaultImmutableConfiguration means that
you have one immutable snapshot of it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: MutableConfiguration Proposal Summary -- optimize for memory consumption?
Posted by Anton Tagunov <at...@list.ru>.
Hello, guys!
Farr> b) Should MutableConfiguration extend
Farr> Configuration?
LSU> public class DefaultImmutableConfiguration
LSU> implements Configuration
LSU> {
LSU> DefaultImmutableConfiguration (Configuration config)
LSU> {
LSU> ...
LSU> }
LSU> }
LSU> The constructor will do a deep copy of the supplied
LSU> Configuration, thus ensuring that the instance is immutable.
The class looks usefull indeed.
One reservation nevertheless:
* the main use case is to allow different storage
structures behind MutableConfiguration
right?
* this is done to choose between
- faster
- low-memory-footprint
implementations depending on evironment
(desktop/server/Java2ME)
and size of configuration provisioned
right?
*IF* both answers are 'yes', then I'd prefer not to
deep-copy the configuration data unless it's unavoidable
If we want to conserve memory then I'd go about it like
once the container has passed configuration to client
that will hold on if for ever and ever, the container just
stops modifying it.
Thoughts?
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration Proposal Summary
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> a) Where does it belong?
Can we solve this by a simple majority vote?
1. avalon-framework-api
2. avalon-framework-spi
3. avalon-framework-impl
Everyone casts a vote for any repo where they want it.
(Mutliple choices allowed.) Then we take the one
with the most votes and just go with it.
Not optimal for anyone, but I've read arguments
for all three, and they have about equal weight in
my mind.
> b) Should MutableConfiguration extend
> Configuration?
Problem here being that a component may
downcast from Configuration to MutableConfiguration.
An upcast from MutableConfiguration to Configuration
should be no problem - but...
I read the javadocs for Configuration and it states
that a Configuration is immutable. The question now
is: for how long? Is the Configuration passed to the
component immutable for the duration of the configure()
call or for all time? If the component keeps a reference
to the Configuration passed in, is the Configuration
guaranteed not to change for as long as the component
holds the reference?
We have to assume that component writers think so.
Therefore, a MutableConfiguration isa Configuration in
terms of methods implemented, but not in terms of
immutability. However, for functions that only rely
on the Configuration being immutable for the duration
of the call, it can be. For example:
public class MyUtils {
public static void serialize (Configuration config) {
...
}
}
In this case, the serialize method expects the configuration
not to change while it is executing - but what you do with the
configuration after you have called it, it doesn't care about.
I propose the following: I'll code a class that is called
DefaultImmutableConfiguration. It will only expose the Configuration
interface, and it will look like this:
public class DefaultImmutableConfiguration
implements Configuration {
DefaultImmutableConfiguration (Configuration config) { ... }
}
The constructor will do a deep copy of the supplied Configuration,
thus ensuring that the instance is immutable.
Then, you can pass in the DefaultImmutableConfiguration to
any client that expects to hold on to a reference for ever and ever,
and you can just pass your regular MutableConfiguration to
the methods that just require the configuration not to change
at all.
Note regarding the name: Yes, I know that we should have:
class DefaultConfiguration implements Configuration
and:
class DefaultMutableConfiguration
extends DefaultConfiguration
implements MutableConfiguration
and not the thing I proposed:
class DefaultConfiguration implements MutableConfiguration
class DefaultImmutableConfiguration implements Configuration
But I can't do it the proper way due to backwards compat.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration Proposal Summary
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK people, let's try to wrap this one up - one way or
another...
Are there any other issues besides the ones listed
by Aaron? That is:
a) Where does it belong?
b) Should MutableConfiguration extend
Configuration?
/LS
> From: Farr, Aaron [mailto:Aaron.Farr@am.sony.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org