> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > >>* there is no fork of Merlin that I am aware of > >> > >> > > > >A fork is something that started in one repository and for > some reason > >is moved to another while the original code is still maintained > >separately. Therefore, in the purest sense Merlin 2 is a fork of > >Merlin 1. > > > > Exception that Merlin 1.0 (which is still in use during Merlin 2.0 > development) is not the code base for Merlin 2.0. Merlin 2.0 was > started on a clean sheet of paper. Merlin 2.0 represents an > evolution > of the Merlin 1.0 concepts. Therefore, in the purest sense, > Merlin 2 is > a fork of the Merlin 1.0 concept. > > ;-)
You seem to intermix evolution and revolution. Evolution means we have gentle change that does not necessarily break things. Evolution would have Merlin 2.0 work in the same project space, adding features and deprecating old code. Revolution is a non-compatible code change. If a Merlin 1.0 container cannot function directly in a Merlin 2.0 environment (without any wrapper/glue/compatibility code) then you have a revolution, not an evolution. > >>* there isn't a fork of the proposed extension mechamism > >> > >> > > > >Your version was a fork of the one in Fortress. You developed it > >independently without discussing with us why we made the > decisions we > >did. > > > > > > No, that's not actually correct. > > The initial extension implemetation inside Merlin was written > in a way > that look into account the meta-info and meta-data context present in > the Merlin Framework. Yes - there was extensive review of > the Fortress > implemetation - but it wasn't a fork. The work from Marcus > in Fortess > supplied the inspiration but the implementation focussed on resolving > how to achieve equivalent functionality in a meta driven environment. > When that excersice was completed - thare was discussion and > exchange > between Marcus, yourself and myself concerning the development of a > common set of interfaces that would enable the different > implemetation > approachs to be interopperable. Hmm. According to http://marc.theaimsgroup.com/?l=avalon-dev&m=102832916123388&w=2 you had a slightly different story. "I started off with the Fortress classes and progressively eliminated them - not by choice but more out of seperation of what's container concern from the extension issue. What I came down to was one interface that needs to be published - the rest is an implementation issue...." That is where I got the concept of your version being a fork, and we finally came to a resolution on the interfaces later--which was neither your original or Marcus' original version. > >Then we need to address exactly how much of a system > *should* be made > >dynamic. And forgive me for being pedantic, but shouldn't > we have just > >one meta model? Merlin==Fortress==Phoenix? > > > > Probably not. > Fist of all - lets look at what a meta-model contains. > > * meta-info, descibing a type of component Which absolutely needs to be the same. > * meta-data, describing profiles of deployment of a particular > component type > > Getting in place a common meta-info layer for an Avalon > component is reasonably strait-forward. This has been the > objective of the work put into the excalib/meta package. Ok. > When you get into the meta-data layer you start to see very > significant differences between containers. For example, > Phoenix meta-data boils down to the descriptions of component > associations and component configuration declared in the > assembly.xml and config.xml files. In Merlin the meta-data > is expressed under a XML file that describes the kernel and a > container hierachy, together with explicit component > declarations within a container declaration. Bottom line: I want to write one deployment descriptor and have it work with whatever container. That is what J2EE affords, and I don't think it should be that hard to determin what a container *really* needs. > In effect the meta-data layer is where container inovation > will occur for the vast majority of cases. Maybe. There are innovations in efficiency, scalability, etc. that are much more compelling than meta-data. > >I dislike too much stuff happening behind the scenes so that > I have no > >clue what is going on. > > > > I don't know what you referring to here. > Certainly nothing in the Merlin 2, lifecycle work, or meta > model work has been behind the scenes. Despite the documentation that is on the site--well, actually on the osm.net site (we should keep the Avalon site the most up to date for Avalon code)--I don't have a clear picture of how things get instantiated or how components get resolved. Sure there is the markup, but as far as I can see, the decision process over which implementation to provide to a component interface is black magic. Sure I could go through the code, but I don't have time for that. The Javadocs don't offer any more of a clue than the rest of the site. > >>>The major distinction is that Merlin has support for Stage and > >>>Extension meta info. I need some clarification on the Stage > >>>meta info--if it is referring to Stephen's first cut at > >>>forking the extension mechanism then it needs to die. If not, > >>>then I need to know what it is talking about. > >>> > >>This is all documented. Please refer to the following page > >>and the respective javadoc on the meta-info types under the > >>org.apache.excalibur.meta.info package. > >>http://home.osm.net/doc/merlin/extensions.html > >> > >> > > > >I'll look at the document, but can you just say 'Yes' or > 'No' and then > >provide the link for further clarification? It'll make > things quicker. > > > > > > If the question wasn't loaded you would probably get a strait answer! How do you mean loaded? You had an interface called "Stage" that was your initial replacement for the extension mechanism. I wanted to make sure that you weren't referring to that. What's so loaded about that? > >>Technical: > >> > >> ContainerKit meta-data model cannot be used in a context > where you > >> dynamically create associations between type profiles. This is > >> brought about by the problem that the entire conterkit structures > >> are immutable. This prevents dynamic construction and the > potential > >> for dynamic replacement. > >> > >> > > > >Would it be able to regenerate the meta-data model when we reload > >configurations? > > > > Yes. > The model currently provides support for the dynamic binding of a > candidate service provider with a target consumer component. The > intention is to be able to re-bind serivces so that a > container can be > dynamically reconfigured (for example, in an edditor within which an > assembler disable one compoenent - Merlin automatically establishes > alternative candidates and defaults, and the assemble can select > prefered solutions or run using default solutions). I would like to make the ContainerKit work for providing a list of components which implement a role/interface. Let the Container itself choose which implementation to provide. > >We can make ContainerKit allow dynamic reassignment. > > > > > > There is absolutely no techical reason why not. > However, you may run into some operation difficulties along the way. Such as...? > >> ContainerKit attempts to define too much about how a > >>container should > >> be implemeted, resulting in a very large redundancy of > classes. The > >> only realistic approach to building a common container > >>utilities group > >> is the progressive defintion of areas of common concern, > progressive > >> collaboration between parties with different solution, > and from that > >> the establishment of sharable utilities. > >> > >> > > > >Could you give me an example where the ContainerKit model > artificially > >constrains you? > > > * lifecycle tools proved insufficient when dealing with > configuration and context management Configuration and Context Management are really container domain things. The Container decides when and where to load the configurations. It sets up the context objects for the components that use the system. I don't really see that as the responsibility of the ContainerKit. > * kernel, lifecycle, processor, and verifier packages all use > the static meta-data model (you cannot use these resources > unless you accept the liimitations of the meta-data > implementation) Once a component is loaded, its meta-data doesn't change. When we reload a component, we might have a different version so we need the meta-data to be set then. I am not familiar with Kernel and Processor in the ContainerKit context. I know the Kernel is traditionally the root container of containers and sets up the root services that the other containers would use. > * imputable contructors prevent any possibility for extension > of base classes for dynamic applications If we need to change constructors we can cross that bridge when we get there. I like things that are simple to use. > * assembly strategy is based on the Phoenix static assembly model > - it does not provide sufficient flexibility for the adative > approach used in Merlin to automate assembly activities and > will not support the partial modification of structures - in > Merlin the container represents someting reconfigurable - using > the containerkit approach you would be forced to rebuild the > entire hierachy, not just a single container That is something we need to fix, but we should be able to do it. We should be able to have ContainerKit follow the example of Merlin in this case. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
