You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Anton Tagunov <at...@list.ru> on 2004/02/04 12:52:29 UTC

Re[2]: MutableConfiguration

Come on guys, be nice! :-)


LSU> MutableConfiguration ... to plug what ... a hole in 
LSU> the Avalon architecture - that we had no interface abstraction
LSU> for DefaultConfiguration.

Do you feel there's same hole also with

* DefaultServiceManager
* DefaultContext

I would say yes. And if we abstract them all into
interfaces the framework-spi.jar seems to gain some
flesh

Anton


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


RE: Re[2]: MutableConfiguration

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> -----Original Message-----
> From: Anton Tagunov [mailto:atagunov@list.ru] 
> Sent: den 4 februari 2004 12:52
> To: Avalon Developers List
> Subject: Re[2]: MutableConfiguration
> 
> 
> Come on guys, be nice! :-)
> 
> 
> LSU> MutableConfiguration ... to plug what ... a hole in
> LSU> the Avalon architecture - that we had no interface abstraction
> LSU> for DefaultConfiguration.
> 
> Do you feel there's same hole also with
> 
> * DefaultServiceManager
> * DefaultContext
> 
> I would say yes.

On those two we may have promised some things that makes
an abstraction harder.

For example, while a Configuration only stores primitive
values and strings (boolean, int, float, String), a Context can

 + be cast-able to a container-specifc context interface

 + contain much more complex objects

See the Javadocs for Context to see what we have promised so 
far.

What it means is that instead of a "MutableContext" we may want to
call it "MutableBasicContext".

For ServiceManager, it would be MutableBasicServiceManager. Looking at
Merlin, while it is easy to figure out how to get things out of a SM,
the semantics 
of putting stuff *into* it may be a bit harder, since the things you put
in (components)
are managed, proxied etc. etc., while the values you put into a
configuration are
immutable and just held.

That said, I'd be +1 to plugging those holes as well (if they can be
plugged).

/LS


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