Hi, I just realized that passing CompositeProcessor to the Builder is not possible since that results in a circular dependency. Maybe we could consider moving the 'write' functions to an appropriate 'Util' class.
Also, I might need the xpath evaluate method in the PropertyUtil class of the assembly module. This method is private now. I am intending it to relax this to make it visible within package. - Venkat On 8/17/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi, > > The PolicyFwk specs mentions that when checking out the applicability of a > PolicySet over a binding or implementation, an xpath expression specified in > the 'appliesTo' attribute of the PolicySet Defn, should be run against the > parent element of the binding or implementation. Since this validation is > done during the build phase, I am a bit lost of how I could get hold of the > scdl fragment of the parent element of the binding or implementation. > > One option I have in mind for this, is to split up the 'write' method in > the CompositeProcessor into smaller methods such as writeComponent or > writeComponentService and so on. Then its a question of invoking one of > these methods from the build phase. But the problems I see with this are : > - > - making the CompositeProcessor instance available to the > CompositeConfigurationBuilderImpl which could probably be done during > construction of CompositeConfigurationBuilderImpl > - the services or referneces or components that we might have at the build > phase may not quite reflect exactly what was in the scdl as there is quite a > bit of reconciliations and normalizations that they undergo. But for the > current context, it should not matter much. > > Thoughts ? > > Thanks > > - Venkat >
