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
