Hi Dan, Thanks for your explanation. Maybe both of your suggestions seem to have some use cases.
Introducing a new option "assertUnknownAssertions" would be a simpler approach if you know you will be ignoring those assertions and also willing to take the risk of automatically ignoring some future assertions that might or might not be handled. Introducing a new property to configure a list of automatically asserting assertions would be a safer approach that ensures that you are aware of those assertions and hopefully have handled them using other means. And you will be notified when a new unknown assertion is added into the WSDL, as your client will fail in this case. If we have to choose between them, I think we probably should choose the second option. regards, aki 2011/9/20 Daniel Kulp <[email protected]>: > > 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 >
