I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it.
1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way "up" the model (component, etc) if it needs to? 5. It might be nice for the PolicyHandlingInterceptor constructor to make an initialization call to the handler so it can do some setup. 6. If policy sets are attached to the operation, JavaPolicyHandlingRuntimeWireProcessor uses the handlers associated with those policy sets instead of the handlers associated with the component level. I don't think this is completely right. It should be possible to use a policy from one domain (say security) for a given operation while using a policy for another domain (say transactions) at the component level. The section of the Policy spec dealing with operation-level attachment for implementations does not address this point specifically. However the section on operation-level attachment for bindings does offer this: "...operation-level policySets override corresponding policySets specified for the binding (where a 'corresponding' policySet @provides at least one common intent)." 7. JavaPolicyHandlingRuntimeWireProcessor adds the interceptor to the end of the invocation chain. In the case of chains for oneway operations, this places the interceptor after the NonBlockingInterceptor. This may present problems for policy handlers such as transactions that are sensitive to running on the thread of execution. It's a bit tricky. For wires into a service, the handler would want to be called after the NonBlockingInterceptor has switched threads. For wires into a reference, the handler would want to be before the NonBlockingInterceptor switches off to another thread.
