The INTENTION of the ignoreUnknownAssertions stuff is to be a parse time
things. With it set to false (which was the default in<=2.2.x ), if an
unnown assertion was found in a policy, it would throw an exception at parse
time. However, that was pretty silly as you could have a policy with
something like:
<ExactlyOne>
<MyKnownAssertion/>
<MyUnknownAssertion/>
</ExactlyOne>
and we COULD use the know version at runtime. That's why the default was
changed. It allowed us to load/process policies with unknown assertions in
them as long as we can normalize down to a policy that only contains known
assertions.
I think what you then want is an extension to that like
"assertUnknownAssertions" that would take this a step further and create an
InterceptorProvider for each of the unknowns as well as an interceptor that
would then assert it. I'm all for doing that, but it is a different
attribute than the current attribute. (I'm actually OK with removing the
current attribute as, at this point, it's relatively pointless, IMO)
More inline....
On Tuesday, September 20, 2011 6:45:33 PM Aki Yoshida wrote:
....
However, when I have such a WSDL with unknown assertions, I am getting
the policy exception at:
Caused by: org.apache.cxf.ws.policy.PolicyException: None of the
policy alternatives can be satisfied.
at
org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(EndpointPolic
yImpl.java:165) at
org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyIm
pl.java:145) at
org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.j
ava:141) ...
(using 2.5.0-SNAPSHOT.)
Right. We couldn't normalize down to a policy containing fully supported
assertions.
I thought this ignoreUnknownAssertions property could help me in this
case. Unfortunately, it didn't and a few things that I saw puzzled me.
1. This property is set in PolicyEngineImpl by the configuration and
it appears that it is supposed to be passed to
AssertionBuilderRegistryImpl where it is set to its local attribute.
In this registry impl class, this property is later used to throw or
not to throw an exception during assertion builder registration.
However, this attribute passing occurs at setBus() method of
PolicyEngineImpl at the beginning and not after
setIgnoreUnknownAssertions() is called. So, no matter how you set
this property in the configuration, AssertionBuilderRegistryImpl
always has this attribute set to its default value of true. This can
be verified in a simple test case where you get the instance of
AssertionBuilderRegistry from the bus and check its
IgnoreUnknownAssertion value.
OK. This looks like a bug. But like I said, IMO, the attribute could be
removed and always be "true". Changing to false wouldn't help your case as
it would (should, but is obviously not working correctly) cause a failure at
parse time, not run time. Still a failure.
2. AssertionBuilderRegistryImpl uses this attribute to decide whether
to thrown an exception in its handleNoRegisteredBuilder method.
However, this exception is ignored in the following
Wsdl11AttachmentPolicyProvider's try-catch block that calls that
method.
} catch (Exception policyEx) {
//ignore the policy can not be built
LOG.warning("Failed to build the policy '"
+ uri + "':" + policyEx.getMessage());
}
So, there seems to be no real effect in setting this property to false
or true to raise an exception.
The real exception comes from EndpointPolicyImpl's chooseAlternative
as shown earlier, as there is no alternative assertion for those
unknown assertions and they are not ignored during this check.
So, this thing confuses me. What is the intention of this
ignoreUnknownAssertion property? Is it for ignoring those unknown
assertions in such cases like I have? If so and it is not working as
intended, can I then correct this behavior? If it is not intended for
this purpose, can someone tell me what its intention is and if there
is a way to ignore those unknown assertions?
There isn't a way to ignore them right now. See above.
Another option I just thought of would be to create a new bean that would
take a List<QName> (or List<String> parsed to qnames internally) that would
register an InterceptorProvider and Interceptor to assert those into the
policy engine. Thus, rather than ignoring/asserting ALL unknowns, you could
configure specifically which assertions you are OK with it ignoring/asserting.
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
