David Bernard wrote:
Hi Stephen,
Thanks for info, but you don't answer those question : * How/When custom container could know/manage context of sub-component?
In Merlin there is a very strict separation of "containment" code from "component" code. Things concerning the creation and supply of context, services, configuration, logging etc. are containment concerns and are handled by the Appliance class. An appliance instance manages a particular deployment scenario (which means that an appliance can be managing multiple component instances that share the same scenario).
You can declare your own appliance implementation - but please keep in mind that your getting into the bowls of Merlin. Chances are rather high that you don't need to go this deep. If you really need to go to the level of plugging in a custom appliance, you should be aware that this appliance abstraction is used recursively during deployment. For example, if I have one component instance - then an appliance instance will exist to handle its deployment. The appliance looks at a component type to see if it has any special lifecycle constraints and if it does (unusual but possible) it deploys another component to handle that constraint - as such we now have two appliance in action - one dealing with the target component and another dealing with a component that exists temporarily during the deployment of the component to handle the constraint fulfillment. In the case of a custom appliance, the appliance instance it is treated as a component and as such you have an appliance deploying an appliance deploying a component. If you look at this through a debugger - it can be a little confusing unless you have a good picture of the internal concepts.
However - if your just looking at getting a hook on the contextualizatioon provision - all you need to do is to declare a custom context provider and Merlin will deploy it (as a regular component) and supply it with the target component during target deployment. An example of this is in the Appliance package test case.
* How/When custom container could acquire reference to ready to use sub-component ?
This is definitely in the area of a custom appliance. The appliance code handles all of the things to do with dependency establishment (assembly) - and the Block class (a specialization of Appliance) exists to handle virtual services (i.e. turning a container into a component).
Can you tell me some more about what your ultimate aim is - because in principal you should not need to extend Appliance or Block unless your getting in real deep (in fact an overarching objective within Merlin is to provide sufficient parameterization points such that actual usage of the API should not been needed except in really special cases).
One problem in the above - Merlin 2.1 does not directly support the
Executable interface. Problem is that the semantics at the level of
the framework are fuzzy here - what to do if a component implements
Executable and Startable? My own thoughts are that this should
qualified as a deployment policy - such that policy (a) results in
invocation of Startable and policy (b) ignores startable and only
invokes Executable. Policies (a) and (b) should be mutually exclusive.
One case when I have Startable and Executable : then component is scheduled (schedule actived with start) but I need the ability to run the action handly, so I use execute() (through JMX or other component).
I've been thinking about this in more detail since I posted my reply and I'm progressively moving towards the position that Executable and Startable may be more problematic that what I suggested. The thing that is bugging me is that while a particular component may have a deployment policy relative to its deployment - we cannot use such a policy globally because consumer components will need a fully deployed componet (which means all dependents that are Startable must be started before we assign references to the consumer).
As to the existence of Executable via JMX - that changes the picture because we are taking about an management operation (as opposed to a potentially inconsistent lifecycle operation).
I'm OK with you, Executable is out of the scope of the Container but aren't exclusive with Startable.
Current conclusion (i.e. state of current thinking that is not necessarily complete):
* Given the existence of Startable and Executable within a given component implementation, Startable shall be applied and Executable shall be ignored.
* A component that implements Executable but not Startable shall be executed following Initialization.
I'll put together a tutorial that demonstrates a custom container.
Thanks. I wrote a HelloContainer but I don't see the difference between Container and component (if container couldn't use, compose sub-component).
There is not any difference between a container and a component (as far as a component implementation is concerned)- the difference rest on how the component (acting as a container) is handled by its appliance. In the case of a component acting as a container - it is handled by a Block - which adds the notions of separation of published services from its internal component structure (implementation).
It may sound complex - but it makes deployment of all sorts of components just plain easy and very reusable.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
