Olaf Bergner wrote:
-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Monday, December 22, 2003 1:02 AM
Project, nor Eve.Also keep in mind that the Directory Project are working on a JNDIThis sounds exiting, yet I never heard about the Directory
InitialContextFactory that includes an embedded Merlin instance (part of
the Eve product) so this could also be leveraged (maybe - we would need
to check with Alex on this).
Any links?The Apache Directory project is an incubator project that is a result of
the
import of the SF ldapd project. At this time they don't have an
Apache site
in place but there is info on the old SF site at this address:
http://sf.net/projects/ldapd - aside from that there is the directory
project
mailing list - and naturally - Alex can provide lots of additional info.
Yes, I found the incubator entry, but the CVS repo on apache is empty. I'll check it out from sf then. Thanks, that'll probably help.
CVS is empty because there using SVN.
To-date the documetation on Merlin has focussed on usage by the component developer and assembler. The documetation concerning usage of internal api is not in place - for example - how to embed merlin - manipulation of the metamodel, etc., etc.
Manipulation of the metamodel? At runtime, programmatically? Is merlin aware of changes made to the metamodel after a deployment has been established, and will it adapt accordingly? This sounds exciting.
Not yet.
What you can do setup the metamodel then deploy, then sometime later - decommission, modify the model and redeploy. The model in general has been designed with the objective of active change (along the lines your suggesting above) - but there is still lots to do on an internal meta-model event model before you will be able to trigger things like redeployment based on a model change (but that's the objective).
So much to do, so little time ;) Just try to keep your head oneinch above
the surface. Honestly, while not being an expert in this field, I do feel that JMX would be a viable road to follow. How about utilizing the commons-modeler package?
It's been a long while since I looked a commons-modeler. WOuld it help at tool level (e.g. JMX generation of descriptors etc. or am I totaly off track)?
My attention was drawn to commons-modeler by it being mentioned as a core technology in tomcat 5. Following the article and a rather casual look into the docs I see two core concepts:
(1) Model MBeans and their metadata are described in an xml config file, thus obviating the necessity to write those MBeans.
(2) commons-modeler puts a facade called Registry before the MBean server. This registry will read in the xml descriptors, instantiate the corresponding MBeans, store the in the MBean server and subsequently manage them.
So one could describe merlins building blocks as mbeans-descriptors, write a bootstrap class that takes those descriptors and builds a kernel from them which will be stored in the registry/mbean server. Does this make any sense?
Yep - makes sense. Just for reference there is also the approach used in Phoenix which is basically to markup a component with tags and from that autogenerate the MBean. Also there may be content in Geronimo - don't know how far they have got on this area.
If you have access to a block then your basically emprowered to do a lot
Could you elaborate on this?(a) dynamic service aquisition is[n't] available yet (i.e. lookup of a service without declaring a dependency) bu this is easy to do if you emabedding merlin
of stuff. You can reach in a locate nested blocks, appliance instance,
resolve blocks and/or applicaes to services, manipulate the meta model,
decommission component, modify configurations, recomission, etc.
However - this is deep into the internals. Its basically what Merlin
uses to do its stuff. If fact - the "merlin" content is rather thin -
the real content is in the composition and activation packages.
See above. Sounds great. Right now, I am struggling with understanding the source. At least in so far that I can get a birdeye view of what's going on in merlin. Its strength seems to be based in large parts on making implicit knowledge about the deployed app explicit. But after all, that's what metamodels are about.
Understanding the source code is easier if you think of the following stack:
|-------------------------------------------------------| | merlin | | | | # setup of internal *facilities* (application repo, | | # logging, root classloader, root block, etc.) | | # Main abstraction is the Kernel which is created | | # the avalon-repository factory loader using the | | # factory declared under the merlin.implemention | | # property. | |-------------------------------------------------------| | avalon-activation | | | | # *runtime* deployment and decommissioning, | | # auto-assembly, lifecycle management, lifestyle | | # management etc. Main abstractions include | | # Block and Appliance | |-------------------------------------------------------| | avalon composition | | | | # immutable *metadata* that describes component | | # deployment scenarios, classloader, containers | | # and a meta-model which combines metadata, meta | | # info, and runtime context - e.g. | | # DeploymentDirective, ContainmentDirective, ... | |-------------------------------------------------------| | avalon-meta | | | | # immutable *metainfo* describing component types | | # e.g. Type, DependencyDescriptor, | | # ServiceDescriptor, ...) | |-------------------------------------------------------|
Currently the logging system is inside the composition package but this something that should be refactored. Instead I would like to see the logging aspects seperated out into an independent facility that we load using avalon-repository.
Cheers, Stephen.
Thanks for your help,
Olaf
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
