Re: svn commit: r531684 - in /incubator/cxf/trunk: distribution/src/main/assembly/ rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/ rt/transports/http/src/main/java/org/apache/cxf/transport/http/ rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/ rt...

[Andrea Smyth <an...@iona.com>]

dandiep@apache.org wrote:

>Author: dandiep
>Date: Mon Apr 23 19:30:43 2007
>New Revision: 531684
>
>URL: http://svn.apache.org/viewvc?view=rev&rev=531684
>Log:
>o CXF-593: MTOM Policy support from Chris Moesel with a few slight modifications
>o Changed the PolicyVerificationOutInterceptor to check assertions using the
>  EffectivePolicy (and hence select the most appropriate policy) instead of 
>  doing an arbitrary check() on the first policy available.
>  
>
Hi Dan,

This was not an arbitrary check on the 'first policy available' but on a 
previously chosen alternative.
There is only ever one policy - at least on the outbound paths where we 
know message and operation type for the underlying message, but this 
could have several alternatives. Although this would be unusual, the 
effective policy could be:
<wsp:Policy>
    <wsp:ExactlyOne>
        <wsp:All>
           <mtom:OptimizedMimeSerialization>
        </wsp:All>
        <wsp:All> 
            <wsam:Addressing>
                <wsp:Policy ...>
            <wsam:Addressing>
        </wsp:All>
    </wsp:ExactlyOne>
<wsp:Policy>

meaning that to support one of the alternatives we need either the 
addressing interceptors or the mtom interceptor on the path, but not both.
There are two options now:
a) The policy framework chooses the alternative upfront, installs only 
one set of interceptors. In that case it only needs to verify at the end 
of the chain that all assertions in the chosen alternative have indeed 
been asserted (the addressing interceptors may have failed in asserting 
the addressing assertion depending on the content of the nested Policy).
b) The other option is to defer the choice and add both addressing and 
mtom interceptors (in general: interceptors for all assertions types 
occurring in any of the alternatives), and then check if there is one 
alternative for which all assertions have been asserted (this is the way 
it is done on the inbound paths on client and server side).
The advantage of a) is that limiting the number of interceptors is 
beneficial to performance (e.g. no encoding/decoding of headers).
The advantage of b) is that we maximise the chances that the message's 
effective policy is supported.

If this merge is intended to use b) instead of a) then it is incomplete 
as the initialisation phase in EffectivePolicyImpl (calculate effective 
policy, choose one of its alternatives, determine interceptors) needs to 
be changed accordingly. getChosenAlternative() becomes meaningless and 
should be removed from API and implementation.
Also, if the EffectivePolicy object is added to the message in 
ClientPolicyOutInterceptor and ServerPolicyOutInterceptor then it should 
also be added in ServerPolicyOutFaultInterceptor.

If not, then what are the intentions instead?  As it stands the effects 
are rather limited - they are not a solution to the problem brought up 
in the discussion about the MTOM interceptor's need to know if a given 
MTOM assertion is optional.
 
Regarding the WSPolicyFeature: How are they hooked up with the Policy 
Framework? From what I can see they use the AssertionBuilders to parse 
child elements and enable the framework. But that alone does not have 
much effect. In particular, no interceptors will get added when a 
message targeted at that endpoint is processed. For that to happen the 
policy framework needs to make the connection between the policy and a 
policy subject (service, endpoint, operation, message). Clearly there is 
an implied association here between the Policies in a WSFeature and the 
endpoint to which this feature applies.
But how should these Policy - (endpoint) subject associations be 
reconciled with other, possibly more fine grained associations, to 
operation or message  subjects?  Or with the association between another 
Policy and the service subject?
To me the obvious answer would seem to treat them  in just the same way 
as Policies attached to elements in the underlying wsdl or Policies in 
matching PolicyAttachment,  i.e. to combine (merge) them with other 
Policies applying to the same subject and to other subjects within the 
same scope. If  there are no objections that's what I will do.

Andrea.

>o Fix bug where the transport tried to apply policies to EndpointInfos without
>  a ServiceInfo.
>
>
>Added:
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/mtom/
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/mtom/MTOMAssertionBuilder.java   (with props)
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/mtom/MTOMPolicyInterceptor.java   (with props)
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/mtom/MetadataConstants.java   (with props)
>    incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/mtom/MtomPolicyTest.java   (with props)
>    incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/mtom/mtom-policy-optional.xsd   (with props)
>    incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/mtom/mtom-policy.xsd   (with props)
>    incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/mtom/nonmtom.xml   (with props)
>Modified:
>    incubator/cxf/trunk/distribution/src/main/assembly/bin.xml
>    incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/EndpointImpl.java
>    incubator/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/ClientPolicyOutInterceptor.java
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/PolicyVerificationOutInterceptor.java
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/ServerPolicyOutInterceptor.java
>    incubator/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/WSPolicyFeature.java
>    incubator/cxf/trunk/rt/ws/policy/src/main/resources/META-INF/cxf/cxf-extension-policy.xml
>    incubator/cxf/trunk/rt/ws/policy/src/test/java/org/apache/cxf/ws/policy/PolicyVerificationOutInterceptorTest.java
>    incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/mtom/ClientMtomXopTest.java
>
>  
>