You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2004/02/03 17:36:57 UTC
[RT][merlin] interoperability
Hi gang,
spent some time chatting with steve last night, about, among other
things, interoperability between merlin and other container solutions.
There's several ways to manage interoperability...
Interoperability types
----------------------
1) component contract support. Steve has explained that the merlin model
will change to support different container-component contracts. This is
basically a merlin-internal design issue.
2) assembly contract support. Like being able to read phoenix
configuration files. While its probably possible, I don't really see
this one happening.
3) code-level integration. There's two kinds:
a) passing an initialized merlin instance could be passed on to
PicoContainer to use a parent container, or to jicarilla as a dependency
provider.
b) passing an initialized instance of XXX on to merlin as a dependency
provider. Option (b) requires significant change to the merlin model and
will likely not be explored in detail until the merlin internals
stabilize somewhat more. It's currently hard work.
my interest is in option 3a).
The basic interoperability use case, 3a)
----------------------------------------
After creating a merlin instance in whatever way makes sense, an entity
(or several that can be masked using the facade pattern) needs to be
exposed that supports the following logical operations:
Object get( Object key );
boolean contains( Object key );
void release( Object componentInstance );
DescriptorStuffOfSomeKind keys();
Steve has explained to me that these operations are in some way buried
inside a fully deployed DefaultContainmentModel (and materials
accessible from those).
The idea is to figure that out and define a graph walker of sorts that
retrieves and releases things from and to the model. This walker can
live in merlin as some module and be reused in other container models.
I bashed my head against that a little last night, but it didn't work.
any takers?
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT][merlin] interoperability
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 04 February 2004 15:52, Leo Simons wrote:
> why would you want listeners?
So that a component can be replaced on the fly, without unloading everything.
It is also a necessity for a Jini-driven service discovery mechanism under the
hood, where services may or may not be available, come and go and so on...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT][merlin] interoperability
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> 3.3 <snip/> walk-in-the-park.
is there a timeline to look at?
> exposing a Object get( key ) - I think that instead we
> should be thinking more along the lines of
>
> void addServiceAvailabilityListener(
> ServiceAvailabilityListener listener, Something key );
>
> Thoughts?
well, that could work, but my listener would just be maintaining a map
internally of available services and still exposing the get() operation.
I was thinking of a stateless adapter, which is automatically in sync
with current state, without being notified. Easier for my usecase.
why would you want listeners?
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT][merlin] interoperability
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> spent some time chatting with steve last night, about, among other
> things, interoperability between merlin and other container solutions.
> There's several ways to manage interoperability...
>
> Interoperability types
> ----------------------
> 1) component contract support. Steve has explained that the merlin model
> will change to support different container-component contracts. This is
> basically a merlin-internal design issue.
I would use the word "adaptive" as opposed to "change". For example one
should be able to substitute a A4 model with an A5 model, or Servlet
model, or even a composite model based on feature recognition of the
target class.
> 2) assembly contract support. Like being able to read phoenix
> configuration files. While its probably possible, I don't really see
> this one happening.
Neither do I.
> 3) code-level integration. There's two kinds:
>
> a) passing an initialized merlin instance could be passed on to
> PicoContainer to use a parent container, or to jicarilla as a dependency
> provider.
>
> b) passing an initialized instance of XXX on to merlin as a dependency
> provider. Option (b) requires significant change to the merlin model and
> will likely not be explored in detail until the merlin internals
> stabilize somewhat more. It's currently hard work.
>
> my interest is in option 3a).
>
> The basic interoperability use case, 3a)
> ----------------------------------------
> After creating a merlin instance in whatever way makes sense, an entity
> (or several that can be masked using the facade pattern) needs to be
> exposed that supports the following logical operations:
>
> Object get( Object key );
> boolean contains( Object key );
> void release( Object componentInstance );
> DescriptorStuffOfSomeKind keys();
>
> Steve has explained to me that these operations are in some way buried
> inside a fully deployed DefaultContainmentModel (and materials
> accessible from those).
The ContainmentModel interface is the root of the application model.
From here you can navigate across the model, access information such as
a components configuration, context model, classloader, etc. Relative to
what you asking for above - the ContainmentModel is what an adapter
implementation would use to handle the above requests.
Currently in Merlin 3.2 and in CVS HEAD the activation package runs the
model and there is plotting and scheming to change such that activation
is nothing more that a model runtime manged by the model. This should
be resolved before closure of 3.3 following which an adapter along the
lines described above will be a walk-in-the-park.
> The idea is to figure that out and define a graph walker of sorts that
> retrieves and releases things from and to the model. This walker can
> live in merlin as some module and be reused in other container models.
>
> I bashed my head against that a little last night, but it didn't work.
:-)
> any takers?
Its all possible now - but it would be better to wait just a bit until
the resolution of the model versus runtime is out of the way. Main
reason is that these changes will impact the kernel definition because
you will no longer be accessing a root block but instead you will be
accessing a root model.
However - I think there is a little more needed on the interface. In
particular - you exposing a Object get( key ) - I think that instead we
should be thinking more along the lines of
void addServiceAvailabilityListener(
ServiceAvailabilityListener listener, Something key );
The listener would be notified once a service is available and more
importantly, be notified of service non-availability (both transient and
permanent).
Thoughts?
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