> -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Monday, December 22, 2003 5:27 PM > > > >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)
Sounds like a lot of hard work. But then again it's a goal worth fighting for. > >>> > >>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. Yes, I am using XDoclet for generating MBean interfaces. Given that there's a xdoclet plugin for maven it makes life a lot easier. However, this is a build-time technology, whereas commons-modeler would allow for easily reassembling merlin's building blocks, i.e. swap different implementations of Kernel, ... I think the geronimo folks are following a similar track, but use standard MLet descriptors for creating the kernel. > > 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. > That surely helps., thanks. Now there's the natural question: what's the semantic difference between metadata and metainfo? It struck me that while metainfo describes a given component's immutable context-independent "structure" (I know it's not the best of terminology) metadata describes one out of possibly many deployment solutions. I know this is possibly not the whole picture, but is it somehow close? Thanks for your help, Olaf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
