Hi Gary: See notes in line.
Gary Shea wrote:
Hey Steve -- I'm getting merlin to work for me, a little at a time. If I can ever get all the way there it'll be great! I've got myself pretty stuck at the moment, need some feedback.
No problem.
Just a comment here - when providing one component as a service to another component, you should really be using the Serviceable interface. While Serviceable and Contextualizable are computationaly similar - there are some import differences. First of all in you case, presumaby you component Y is implementating a service oriented interface which is required by component X. If your assemblying these components manually (i.e. building the context and service manageme object your code), and if your following the framework patterns, you would create an instance of DefaultServiceManager and add component X to the manager under a role name that Y will use to reference it.As I mentioned before, the UI is considered a component in this app. In my current hand-lifecycled version, I have a giant ugly method in which all the ui 'controllers' are created as components, one by one, in a depth-first order wrt the tree of Swing UI relationships. Suppose component X is responsible for displaying Y. First Y is fully lifecycled, then X is fully lifecycled, with Y as part of X's context.
E.g. component X implements a TimeService interface and component Y is a Scheduler that has a dependency on a service implementing the TimeService interface. The scheduler should use the Serviceable interface, under which it is supplied a ServiceManager, and from which it can lookup the time service with a key.
In this scenario, your lifecycle handler you need to know the role name to assign for the different services, and all of your components would need to be careful about using the same role name. That's ok in a limited scenario - but what is even better is if your utility can get the class of the component it is processing, get a bunch of meta information, and derive from that the service defintion and role name that the component needs. This is achieved through the structures in the excalibur/meta package - "the xfiles". The file named <component-classname>.xinfo should contain a <type> element as the root, and within this you can declare a depedency (e.g. the .xinfo for X would declare a dependency in a time service, and component Y would declare that it porvides the time service. If you package this information within "x-files" your application becomes more loosely coupled because you don;t have to follow strinct naming conventions, and keys used to lookup services can be scoped locally within the depedency defintion of the consuming componet.
Ok, enough rambling about that - except to say that all of the above is addressed in the excalibur/meta package and really havn't got into Merlin space yet.
Let's ignore the fact that your example talks about putting a service into a context object and assume instead that your dealing with the problem of populating a context object automatically. At the component meta level (excalibur/meta) you can declare that the component instance implemets an interface derived from the framework Context interface (if nothing is declared for a context type then the framework Context interface is assumed). You can also declare in the .xinfo file <context/> element the entries to be included in the context. Context entries include the declaration of the class of the object that is expected, the context key the component will use to access the context, and if the context entry is required or optional.I think the reason my method doesn't want to work with merlin is that a mapping needs to be created automatically from a deployed component to a context key value! How could merlin know that?
If we move up to the next meta level (refer excalibur/meta/mode) you have the Profile class. The profile class contains a much of structures called directives which let you build an object model of the parameters to be supplied to a component during lifecycle processing. For the context object the Profile type includes support for the declaration of a ContextDirective. A ContextDirective lets you declare two form of context value aquisition:
* importing a context from a container using a container scoped key
* declarative construction of a context object using parameters
Using the excalibur/meta APIs, you can introduce a much higher degree of loos-coupling into your lifecycle utility. You can even take avantage of preconfigured profiles and default configurations - which make life *much* easier for the end user.
Just for clarification - here is the basic seperation that the excalibur/meta package provides, and the seperation I'm working on with respect to synchronizing merlin with the excalibur/meta.
Type Level
An API supplimenting class information with details about
required dependencies, and extensions, service the
component provides, context and logging constraints and
type-level defaults.
http://jakarta.apache.org/avalon/excalibur/meta/type.html
Profile Level
An API that allows the capture of different deployment
profiles - where a profile is a combination of configuration,
context, parameters and logging information. It is possible
for may profile to be declared for a particular type.
http://jakarta.apache.org/avalon/excalibur/meta/profile.html
Appliance
An applicance (not in CVS yet but part of the refactoring I'm
doing in merlin to sync. with excalibur/meta updates) represents
an assembled profile and the access point to the services that
a type provides. Appliance also encapsulates lifestyle
management because this is the object that is used to actually
get an instance of a service.
[no doc yet - working on it]
Instance
A regualar java.lang.Object, established as a result of a
request to an appliance. The identity of the instance is
a function of the lifestyle policy that the appliance is
enforcing. This object is the service from a consumers
perspective and could be a proxy of the component, a
obnject reference, etc. depending on the type of appliance
that is handling activation.
Ok, you now have my permission to add you name to the "Steve's wordy email hate list"!
:-)
Hope this helps!
Cheers, Steve.
Regards, Gary -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
