You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Aki Yoshida <el...@googlemail.com> on 2011/09/20 18:45:33 UTC
doubt on ignoreUnknownAssertions option in ws-policy
Hi,
Maybe I am not understanding how this option is supposed to work. I
see something strange with how this parameter is used and I would
appreciate if someone can clarify my doubt.
I have someone's WSDL that contains their proprietary policy
assertions (e.g., microsoft's policy assertion describing a decoupled
port). I would like to simply ignore these unknown assertions and use
the WSDL as it is to get the other properties extracted from it
because I could just configure the CXF bus explicitly for those
unknown assertions. And I don't want to maintain my own copy of the
WSDL by removing these assertions or adding the wsp:Optional="true"
attribute to those assertions.
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(EndpointPolicyImpl.java:165)
at org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyImpl.java:145)
at org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:141)
...
(using 2.5.0-SNAPSHOT.)
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.
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?
Thanks.
regards, aki
Re: doubt on ignoreUnknownAssertions option in ws-policy
Posted by Aki Yoshida <el...@googlemail.com>.
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 <sb...@gmail.com>:
> 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<dk...@apache.org>:
>>>
>>> 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
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>>
>
>
Re: doubt on ignoreUnknownAssertions option in ws-policy
Posted by Sergey Beryozkin <sb...@gmail.com>.
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<dk...@apache.org>:
>>
>> 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
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
Re: doubt on ignoreUnknownAssertions option in ws-policy
Posted by Aki Yoshida <el...@googlemail.com>.
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 <dk...@apache.org>:
>
> 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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: doubt on ignoreUnknownAssertions option in ws-policy
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com