Hi, I will just introduce a new policy provider in 2.5.0 that can be configured to ignore, or in other words, to automatically assert a set of specified policy assertions, as suggested in the second approach.
This approach will not interfere with the current (minor) use cases of "ignoreUnknownAssertions", so we can independently decide what to do with this property in the future. regards, aki 2011/9/21 Sergey Beryozkin <[email protected]>: > Hi > > IMHO both properties are redundant but I can see why ignoreUnknownAssertions > can be handy: > 1. workaround the policy declaration bugs; for example, > if WSDL in question is declaring a decouple port policy without making it > optional, explicitly or implicitly via providing multiple alternatives then > it has to be understood by a client - but it appears it's an 'optional' > policy so it's a bug in a WSDL policy instance. > 2. As Dan said, if we have > <!-- alt 1 --> > <a><b> > <!-- alt 2 --> > </b> > > where a is unknown to the client, then without this property, the CXF client > will fail, even though it can satisfy the 2nd alt. > Ideally, the exception to do with the unrecognized policy only after the > process of finding the best alternative has been completed. If it were the > case then we'd end up with the alt2 in the end and thus we'd 'drop' the > exception to do with the unrecognized 'a'. But I guess it could be tricky to > implement at the moment. Fixing this would probably make this property > redundant, if it were not for 1 :-), > > Cheers, Sergey > > > > On 20/09/11 23:05, Aki Yoshida wrote: >> >> 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 >>> > >
