avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: MutableConfiguration
Date Fri, 23 Jan 2004 10:07:59 GMT
Leo Sutic wrote on Friday, January 23, 2004 10:32 AM:

> All,
> in the discussion-but-was-supposed-to-be-a-vote of the
> MutableConfiguration interface some questions were raised regarding
> its 
> usefulness, correctness, etc. I'd like to clarify my
> arguments for that interface.
> -----------
> Put simply, the MutableConfiguration interface is the
> interface abstraction of the DefaultConfiguration class. So
> far, we have had:
>    Configuration        - interface - read-only
>    DefaultConfiguration - class     - read-write
> So if one wanted to only expose the read-only parts of a
> DefaultConfiguration, one would specify that a Configuration
> was passed. However, there are times when one wants to pass
> around a writable configuration object. So far, the obvious
> choice has been to pass around a DefaultConfiguration
> instance. But I would prefer if an interface could be passed
> around, instead of locking myself to a specific class. This
> makes for lower coupling.
> ---------------
> The MutableConfiguration interface has nothing to do with
> lifecycle extensions, or component persistence. While one
> surely can design such systems with the interface, the
> existence of the interface does in no way lock us into having
> to use it when designing the persistence mechanism.
> I also do not propose that the component persistence
> mechanism that I use be made part of framework. I merely
> brought it up to illustrate how *I* intend to use the
> interface. Another use would be internally in a container: when the
> container wants to alter a configuration before giving it to
> a component and doesn't want to pass around a concrete class
> to the parts doing the alterations.
> The interface is not a part of the container-component
> contract, as it does not exist in any of the lifecycle
> interfaces. In the future, should we decide to create new
> framework-level interfaces, it may - but that's for the
> future, and then only if a case can be made for it.
> ------------------------
> Because DefaultConfiguration, which is the (I believe) by far
> most commonly
> used example of a mutable configuration object, is in
> framework. Putting the interface in Excalibur would mean that
> the class that is the prime example of an implementation of
> it would not implement the interface. This makes no sense.
> I have no problem putting it in avalon-framework-impl instead
> of -api,
> though.
> /LS

Hi Leo,

just my thought on this topic. When here on the list was a talk of JMX I always had the impression,
that we talk about a solution to make any *existing* component JMX endabled. The MutableConfiguration
would allow an developer to implement components that have the ability, but it does not solve
my problem to configure e.g. the used data store component. For existing Avalon components
you will have to set them free them and create them new, otherwise you'll break their contract.
This is obviously not what you always want, but IMHO the only compatible way. In your scenario
a developer has explicitly to design his components for this ability, but all of the old and
a majority of new components will ignore this and leave me as user with no JMX support at

Speaking of Fortress an approach would be to use an JMX enabled container, that delivers its
component with proxies, that can handle hotswap. For Merlin, I have a lack of knowledge of
the architecture, so I'll just wait and see, what's coming up.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message