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]