avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Component Meta Model Wars--Resolution time?
Date Tue, 20 Aug 2002 19:49:13 GMT


Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>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.
>

And the point is?

The end result was the defintion of a couple of interfaces which was the
result of the work from Marcus and myself. That's consitent with you
reference, its consitent with what I said above.  Its consistent with the
names in the source.  

Sorry, It's really not clear to me what your getting at.


>>>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.
>

Keep in mind that this is an order of magnitude more complex than
anything discussed so far.  This would require reolvution of issues
such as block and application listeners in Phoneix, hanlding
intercepts, packaged deployment descriptors in Merlin, container
hierachies. Etc.  

I don't think we will see this any time soon.  

>
>>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)
>

It's desirable but it also takes a lot of time. All of the content
has to be checked in as individual CVS entries and that is a real
pain.   If it were possible to supply upload a single zip containing
the javadoc distribution then this could be maintained near real-time.  
As it stands the amount of time needed to do an update means that
this will not happen more than once a month.  As this is pre-release,
I don't see this as a problem.

>--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 information is there in the javadoc - but you have to know where to
look.  There is a lot of this sort of bigger picture information that
is needed (as per my earlier comment concerning priorities).  Don't
worry - it will come.  In the meantime if you have a specific question
such as "how does Merlin select a component during assembly" then post
a email to the list and I'll be happy to provide details and pointers.

>
>
>>>>>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?
>

Loaded in that you implied a fork of the extension mechanism which I
already pointed out to you was not fork. Loaded because there have been
a lot of emails discussing "the first cut" and details of the evolution
of that to the implemetation to its current form and the suggestion
that maybe maintaining the first cut indepedently of all of that dialog
- its a little confusing.

>
>
>>>>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.
>

The seperation you talking about is exactly the line drawn in defining
the content in the meta-info model that I've just moved to excalibur/meta.
This seperates the type information that a container needs to determine
candidate suppliers of a particular service interface (role), and
candidate extension supplier for a particular extension stage.

The actual management of selection is at a higher-level and is driven
extensively by meta-data.


>>>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...?
>

I hope you don't mind but I will refrain from answering that one.

>
>>>> 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.
>

They should not be - its the interfaces and classes in containerkit
that are inappropriate when attempting to build a container.  The
problem is that containerkit isn't just low level stuff - is goes
all the way up.  Utilities are one thing but containerkit is a full
container implementation that's based primarily on the Phoenix
assembly architecture.  When you say containerkit - keep in mind what
containerkit is.  A would not be too suprised in the containerkit
kernel cound itself as a kernel in Phoenix - because that would make
sense in the architecture of Phoenix.  

If containerkit were refactored to use the excalibur/meta package
then a lot of harmony would fall in place.  Containerkit evolution
could continue just as Phoenix and Merlin evolution can continue. In
the meantime we would all be working of the same sheet of paper at the
level of the meta-info we are using.

>
>>  * 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.
>

Correct.

>
>
>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.
>

And the simplest solution is for containerkit to reuse the meta-info model
under excalibur/meta.  It covers the complete spectrum and is well 
documeted.
It provides support for loading type.dtd, blockinfo.dtd and 
containerkit.dtd.
It also includes specific support for create of a Type meta-info from any 
of these DTD sources.  It does not contain any extra bagage and is 
completely
indepedent of anything except the Avalon framework and i18n.

Cheers, Steve.

-- 

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-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message