tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Edwards <mike.edwards.inglen...@gmail.com>
Subject Re: [2.x] builder woes
Date Thu, 06 Aug 2009 14:14:15 GMT
Simon,


Simon Laws wrote:
> I started looking at ASM_9004 a couple of days again and various fixes
> are needed in the builders. Having worked with the builders for a long
> time I've come to the conclusion that their current configuration,
> which has evolved over the last couple of years, has become
> un-maintainable. The primary reason for this is the jumble of logic
> across the 14 active builders we have. It's very difficult to spot and
> isolate what rules are being applied to the creation of the model and
> hence whether these rules comply with the specs.
> 
> Given that we have a model that combines both a representation of the
> static assembly model and the runtime model that is derived from it
> (I'm not brave enough to suggest that we move away from this
> configuration) I think there are a number of distinct phases the build
> phase has to go through. The primary thrust of this is to move away
> from the seemingly arbitrary and inconsistent traverses through the
> model toward a clearly defined pattern of processing.
> 
> ============
> 
> Pre-processing
>   rationalize includes
>   etc.
> 
> Static model processing
>   build the component type of each composite (non-composite component
> types are previously calculated at the resolve stage)
>      Apply the OASIS rules for promotion of
> properties/services/references/policy
>   configure each component based on its component type
>     Apply the OASIS rules for promotion of properties/services/references/policy
> 
> Runtime model processing
>   augment the static model with the runtime information
>      Component URIs
>      Binding URIs
>      Endpoints
>      Endpoint references
>      etc.
> 
> Post-processing
>   not sure if there is anything that goes here
> 
> ============
> 
> At r801592 I've started adding a ModelBuilder to replace the
> CompositeBuilder to follow this kind of pattern. In reality I haven't
> done much at all and it neither runs nor affects the current builder
> code (it would be switched on via META-INF/services). I want to get
> thoughts on this before spending real effort.
> 
> Regards
> 
> Simon
> 
I have a lot of sympathy with this approach.

The spec lays down rules for the calculation of the componentType of a composite and it lays
down 
rules for the calculation of the configuration of a component involving the componentType
of its 
implementation.  It would be far better to have these two pieces of calculation each tidily
in its 
own place.  At the moment, it is scattered all over the place, which makes it very hard to
pin down 
some of the bugs that the OASIS tests are revealing.

I'm happy to help out building the new code for ModelBuilder that you propose.


Yours,  Mike.

Mime
View raw message