[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avalon-dev
Subject:    Re: Fortress/ECM/Merlin covergence
From:       Stephen McConnell <mcconnell () apache ! org>
Date:       2002-10-28 7:16:56
[Download RAW message or body]



Gary Shea wrote:

>I just joined avalon-users (should have done that a long time ago!) so
>I'll hear more about making assembly a service.  My immediate gut
>feeling is YES, good idea.  I have hesitated to bring full-on fortress
>or full-on merlin into my app just yet, partially because I want to keep
>it light (this is a WebStart app!), and partially because I just don't
>want to take on all that complexity at once.  I love the idea of being
>able to pick up a bit at a time.  
>

There have been some requests/hints for some more "cookbook" style 
documentation - taking a user step by step in the set-up and deployment 
of a system. Possibly something like:

  1. "My First Component"
        - Short introduction
        - Avalon lifecycle overview
        - The xFiles
        - The manifest
        - the <component/> tag
        - example code, xfiles and manifest
        - cookbook resources

  2. "My First Container"
        - Short intro
        - the <container/> tag
        - a quick not on extension directorites
        - the <classpath/> and <logging/> tags
        - an example kernel.xml file and playing with variations
        - cookbook resources

... and then moving into some of the more exotic things   

  3. "Advance Topics"
        - Services and the .xservice resource
        - Lifecycle Extensions
        - Lifestyle management
       
       

>You probably noticed that tendency
>from the openorb days ;)
>

Same here - I remember the process of getting to understand Avalon back 
a couple of years ago - smelt good, felt right, but brought a lot of 
conceptual stuff along with it.

>
>I've gone through the meta site now, bravo on splitting that out.  Good
>political move too of course... he who makes his code easiest to use
>wins the war of standards, assuming marketing budgets are equal.
>

Just for reference - before the end of this year I should be getting 
into meta model extensions.  What I want to be able to do is to have a 
component implementation declare (via a DTD ref) that its using a 
particular meta model extension - and from that enable things like 
dynamic loading of the appropriate handlers. This would be really nice 
from the point of view of container management tools where you will be 
able to interactively navigate the entire structure and relationships of 
a component/service model.  That should lead to a significant 
simplification for end-users.

>
>I am about ready to try bringing merlin into my app, you'd laugh if you
>saw what I am doing.  
>

Cool - don't hesitate to drop questions to the user list - there are 
several people experimenting with Merlin 2 so there is a good chance 
that questions/throughts you have will be relevant to others here as well.

>I'm almost done retro-fitting each major UI bit as
>a component.  Of course they are not components in the sense of
>something I might try an alternative version of later, but the
>provisioning features of Avalon/merlin component support are too useful
>to let some definition quibble stop me!  At the momeent, all the
>components are hand-lifecycled in the code, so I have a feeling for what
>merlin will be doing for me... wanted to be clear that component-ization
>is worth the trouble for this particular application.  
>

I'm currently refactoring a lot of CORBA related code to leverage Merlin 
- and I'm getting close to dealing with some similar stuff where there 
internal deployment of components (things like creating a new instance, 
setting the logger, context, initialization, etc.).  But its basically 
hard-coding a lifecycle into the code which means two places to change 
if you make lifecycle updates.  With the deployment service that should 
replaceable with a couple of lines and you will have complete assembly 
and lifestyle management for free.

>At the moment
>there's almost no configuration (an occasional fixed height/width), not
>much context, lots of services.  Once merlin is in place, it will be
>very slick.  I'll probably give a talk on it at one of our local JUG
>meetings in a month or two.
>

That's really great - I can provide you with some descriptions of 
applications that are being deployed with Merlin, embedding Merlin, and 
outlook concerning Distributed Merlin (which is slowly but surely 
comming together).

Cheers, Steve.

>
>The beauty of Avalon assembly in Swing is that it really helps flatten
>out the heirarchical Swing code.
>
>	Gary
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-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-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]