Hi, I have changed this now to put the computed intents back into the binding/implementation instance. So the bindings and implementations can now parse the intents and filter the mayProvided ones and take appropriate actions. I'm trying to see if I can get this demonstrated on our axis2 binding.
I've also made some changes to now get the bindingType and implementationType definitions in order. Here is how things should work from now on : - - every binding and implementation type has a definitions.xml file in the META-INF/services directory in which will be defined a bindingType or implementationType element that contains all the intents mayProvided and alwaysProvided by the binding / implementation type. - ever binding / implementation instance will have reference to this corresponding type bindingType or implementationType definition. All this under r614447. Thanks - Venkat On Jan 16, 2008 12:52 AM, Greg Dritschler <[EMAIL PROTECTED]> wrote: > I agree that intents that are listed in mayProvide do not require a policy > set. The binding/implementation provides the functionality of the intent > if > the intent is present on the relevant composite element. It looks to me > that CompositeWireBuilderImpl, as part of the process of trying to find > matching policy sets, removes intents that are found in mayProvide from > the > model object. In that case, how would the binding/implementation know it > should provide the intent functionality if the intent isn't present in the > model anymore? > > Greg Dritschler >
