On Thu, Feb 28, 2008 at 3:58 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Laws wrote:
> > On Thu, Feb 28, 2008 at 9:04 AM, Jean-Sebastien Delfino <
> > [EMAIL PROTECTED]> wrote:
> >
> >> There is a fair amount of special handling code for composites and
> >> policySets in ContributionServiceImpl.
> >>
> >> I guess these are hacked workarounds for some issues? any idea what the
> >> issues were?
> >> --
> >> Jean-Sebastien
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> > This was the pseudo code that Venkat used to describe the "appliesTo"
> > processing here [1].
> >
> > Enhance composite with policy sets based on appliesTo information
> >
> >    1. For each composite file read the xml content first...
> >       1. For each policyset in the domain...
> >          1. Extract the value of 'appliesTo' attribute with is an
> >          xpath expression
> >          2. Evaluate this expression against the composite xml
> >          3. For each node that results out of the above evaluation
> >             1. if the node contains an attribute named
> >             'applicablePolicySets'
> >                1. concatenate to its value, the name of the
> >                PolicySet
> >             2. else
> >                1. create an attribute named
> >                'applicablePolicySet' and set its value to the name of
> > the PolicySet
> >               2. Wherever applicable the composite's elements
> >    will have the additional attribute name 'applicablePolicySets'.
> >
> > Don't know if that covers all of the policy processing in
> > ContributionServiceImpl
> >
> > Regards
> >
> > Simon
> >
> > [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
> >
>
> OK, the algorithm makes sense to me but I'm surprised that it's done in
> contribution-impl. IMO contribution-impl should not have dependencies on
> the specifics of composites and policies and all this work should be
> pushed one level up in the dependency stack.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Well I think this is one of the things that could be usefully extracted
from the contribution service and into a separate "enhance composite with
policy" function. As to where it should go? I'm in a bit of a quandry. It
feels like we need something between what is currently in the contribution
service and some of the things that are currently in policy and in the
assembly builders. Could we have a new module
assembly-processor/assembly-builder/assembly-configurator? where we can put
functions that manipulate an assembly model that has already been read and
where function from other modules needs to be bought together.

I have an interest in this as in looking into the way that we can configure
a domain's composites with any endpoint information we know ahead of
deployment time and will likely want a home for an "enhance composite will
endpoint info" function.

Simon

Reply via email to