Gary Shea wrote:
I just joined avalon-users (should have done that a long time ago!) soThere 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:
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.
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
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.You probably noticed that tendency from the openorb days ;)
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'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.
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 am about ready to try bringing merlin into my app, you'd laugh if you
saw what I am doing.
I'm almost done retro-fitting each major UI bit asI'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.
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.
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).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.
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-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
