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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
