[EMAIL PROTECTED] 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
