Page History

...

<bean class="org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider">
    <constructor-arg ref="cxf"/>
    <property name="location" value="org/apache/cxf/systest/ws/policy/addr-external.xml"/>
</bean>

...

It is also obvious that the above aggregation process can be quite resource intense. Effective policies for messages and endpoints are therefore cached by the framework for future reference. The entity that manages the cache of effective policies is the PolicyEngine.

At the same time of When computing the effective policy for an endpoint or a message, the framework also chooses one of the effective policy's alternatives. Currently, the first alternative that in principle can be supported by interceptors (i.e. for which there is a PolicyInterceptorProvider) or by the conduit/destination is chosen. This choice, along with the set of interceptors (obtained from the PolicyInterceptorProviders in the PolicyInterceptorProviderRegistry), is cached along with the actual effective message or endpoint policy in the form of an EffectivePolicy or EffectiveEndpointPolicy object. In the case of an effective endpoint policy, interceptors are chosen in such a way that the assertions in the chosen alternative of the effective endpoint policy can be supported, but also any assertion in any alternative of any of the operation and message specific policies. This is necessary in situations where the underlying message is not yet knowknown, for example on the server onbound inbound path: Once an alternative has been chosen for the effective policy of the server's endpoint we know which assertions must definitely be supported, regardless the underlying message/operation. Additional interceptors that are necessary to support the assertions that only appear in specific operation or input message policies are added pre-emptively. Note that this relies on interceptors being coded defensively - good practice anyway but especially so for interceptors returned by PolicyInterceptorProviders!

...

The policy framework, when activated (by loading the PolicyEngine and setting its "enabled" attribute to true), installs a couple of interceptors at bus level which execute early on in their respective interceptor chains:

Their main function is to add interceptors that are required to support the effective policy of the underlying message - even if that policy is not yet known at this the point the interceptor executes (because the operation is not yet known).
In case where the effective message policy is known, the assertions of its selected alternative are inserted into the message in the form of an AssertionInfoMap. This way subsequent interceptors need not be concerned about the details of obtaining the effective mssage policy (obtaining the PolicyEngine, knowing which of its API methods to use and how to obtainaing the corresponding parameters for the call) but can simply pick up the AssertionInfoMap from the message and from that obtain a collection of assertions that they can understandis a map, keyed by assertion type name, of collections of AssertionInfo objects, the latter being stateful (asserted/not asserted) representations of Assertion objects.
Where the effective message policy is not known, not only the assertions for the selected altervive alternative in the effective endpoint policy are made available to the messageincluded in the AssertionInfoMap, but also all assertions in assertion in all alternative of all of the operation and message specific policies as well. Not all of them these will be asserted at the end of the chain, but that is fine if it turns out they do apply to operation sayHi when in fact we have been processing a inbound greetMe request!

Policy Aware Interceptors

Policy-aware interceptors extract the collection of AssertionInfo objects for the assertion types they understand from the AssertionInfoMap in the message. They can then use the wrapped Assertion objects to fine tune their behaviour, possibly exhibiting message type specific behaviour, and finally express whether or not they do not actually apply to the undelying message - which at that point is known.

...

could support these assertions. Given an assertion type that has attributes, and assuming there are two instances of assertions of this type, it is possible that the interceptor can assrt one, but not the other assertion. In any case, inability to support all assertions understood by the interceptor does not necessarily indicate a failure. As mentioned above, it is possible that the ones that cannot be supported do not in fact apply to the underlying message at all.
Typically the interceptor would strive at supporting as many of these assertions as possible however, and for that purpose it may avail of the AssertionBuilder's capability to compute a compatible policy. For example, by scheduling an acknowledgement to be sent in 3 seconds, an RM interceptor would support both of the following RMAssertions:

<wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
    <wsrmp:AcknowledgementInterval Milliseconds="30000"/>
</wsrmp:RMAssertion>
<wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
    <wsrmp:AcknowledgementInterval Milliseconds="50000"/>
</wsrmp:RMAssertion>

To sum up, the typical policy specific work of an interceptor would consists in the following:

import org.apache.cxf.ws.policy.AssertionInfoMap;

class MyPolicyAwareInterceptor {
    static final QName assertionType = new QName("http://mycompany.com}", "MyType"});
    public void handleMessage(Message message) {

       // get AssertionInfoMap
        org.apache.cxf.ws.policy.AssertionInfoMap aim = message.get(org.apache.cxf.ws.policy.AssertionInfoMap.class);
        Collection<AssertionInfo ais> = aim.get(assertionType );

        // extract Assertion information
        for (AssertionInfo ai : ais) {
            org.apache.neethi.Assertion a = ai.getAssertion();
            MyAssertionType ma = (MyAssertionType)a;
           // digest ....
        }

        // process message ...
      
        // express support

        for (AssertionInfo ai : ais) {
            ai.setAsserted(...);
        }       
    }
}

Verification

Another set if interceptors installed by the policy framework are respoisble for verifying that one of the alternatives in the effective policy of the underlying message could indeed be supported. These are:

Their behaviour is (if applicable at all) symmetric on client and server side.