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