-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED]
I've just committed an example of embedding merlin so that you can get an idea of things (available in avalon/merlin/platform/tutorials/main).
I hope everyone has taken a look at this example:
http://cvs.apache.org/viewcvs.cgi/avalon/merlin/platform/tutorials/main/src/ java/tutorial/Main.java?rev=1.2&view=markup
Stephen shows a good example of just how simple it can be to start Merlin.
But, of course, that's not the *whole* story. In fact, I've told Stephen
before that I consider that approach cheating. :-)
Grut, spit!
In this email I'm going to try to give a better tour of the "magic" in merlin's startup process.
1. Several properties are set in the 'merlin.properties' file. This includes telling merlin which block to run. To do this programmatically:
Factory factory = builder.getFactory(); Map criteria = factory.createDefaultCriteria(); criteria.put( "merlin.deployment", "conf/demo.block" ); factory.create( criteria );
(this was in Stephen's original version)
2. I'm guessing on this, but if you want to access the kernel, all you need to do is change the above to:
Kernel merlin = (Kernel) factory.create(criteria);
You could do this if you can all of the api jars in the classloader that Main is running in. You do this just by including all of the related jars in the classpath or alternatively, put yourself inside a factory and let you main method create you. You then have everything you need and you still only have one bootstrap jar file.
You can then go about the business of accessing components via the
kernel. But that's for a different email.
3. The repository does all the magic. Specifically, the repository gets all
the info to launch the merlin kernel from a META file:
http://www.ibiblio.org/maven/merlin/jars/merlin-impl-3.3-SNAPSHOT.jar.meta
This file accurately shows you what dependencies are required (three classloaders and 22 jars). It also reveals the next trick.
4. org.apache.avalon.merlin.impl.DefaultFactory does all the work. If you want to *really* see how Merlin starts up, look at this class.
Yep - this class covers the setup of the system internals - the most important of which is the SystemContext. The SystemContext implementation does the work of creating the meta-model factory, putting in place the runtime, bootstrapping the logging system, and finally loading an initial set of level-one containment models.
Now, I like the repository idea. In fact, it's the primary reason I decided to use Merlin in one of my latest apps. However, there are other times when I don't really want to use a repository. In fact, sometimes I want to be able to deliver a single large jar file that includes everything I need.
Can we dig into this a little further. In particular - I'll like to known what the underlying (real) objective is:
1. a "sealed deliverable" (i.e. something that the client
cannot tinker with) ?
2. simple installation without network access ?
3. something else ?With that in mind, I decided to look at how I could start up Merlin _without_ using the repository. So I started with the DefaultKernel class and started tracing back all the dependencies I would need. I only considered constructor dependencies, just the bare minimum I would need to full fill the requirements of the DefaultKernel.
Result? 30+ classes required. And you still need a Repository class. A simple list of the dependencies has been attached for those who are interested.
I had done something similar with Merlin but that was before the whole Repository package. After reviewing it now I see that there isn't any easy way to start up Merlin without a repository and without a bit of meta-info. That's not necessarily a bad thing -- ECM and Fortress generally require external configuration files and a few helper/factory classes.
Something to keep in mind is that the is no reason why we can't provide a sealed repository. I.e. a bootsrapable jar file then contains a populated repository. It would require a special repository implementation (but that's really small - the current default repository impl package is about 15k - and the impl is plug selectable). A sealed repository would need to do some background unpacking into a temporary files as requests are resolved but aside from that I can't think of any major issues.
So in the end, I'm not necessarily encouraged or discouraged. I've been thinking about a number of ways we could make Merlin simpler and give users more options on how to start Merlin and load/deploy their components. My goal is to decrease the learning curve of Avalon so that a new user could get the basics down within an hour. That involves not only better documentation but also a very simple way to work with the container.
Thoughts?
Some basics:
1. Getting in-place nice installers. 2. Doing a detailed review of the container XML for complete consistency. 3. Enhancing and improving the the <fileset> directive (its kind of minimal in terms of functionality). 4. Finalizing the <select> directive to include pluggable logic
The first item (1) is partly about packaging and partly about making the install process easier. Items (2), (3) and (4) are related to making the specification of a composition more intuitive (I think it currently quite good but there are some inconsistencies and shortcomings).
Next on the list of improving the user experience is to enhance the error handling. For example - several exception reports could be consolidated such that instead of 6-8 levels we should be aiming for 1 or 2 levels. This is mainly related to assembly and commissioning errors that generate reports of a length that corresponds to their depth in the containment hierarchy.
Finally - and more directly addressing your question - based on the thinking about the ECM scenario - it sees to me that we could provide a sealed system bundled with a set of standard facilities (service finders, generic factories, query based directories - all basically doing things that make the experience easy within embedded scenarios).
Stephen.
J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | 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]
