cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: CXF-4819 breaking validation of mustUnderstand attribute
Date Thu, 21 Feb 2013 13:18:34 GMT
2013/2/20 Daniel Kulp <>:
> On Feb 20, 2013, at 5:30 AM, Aki Yoshida <> wrote:
>> I still don't think it's a good idea to interfere with the validation
>> in that way by default. As I commented here earlier, the corresponding
>> schema should include the any-attribute declaration if the header is
>> to be schema-validated. I think this implicit handling may lead to
>> confusion when other tools may strictly invalidate those headers.
>> Furthermore, there seems to be another aspect.  Today, I digged a
>> little bit and found that there is a use case to catch this error:
>> here, the mustUnderstand header is declared to be prohibited in the
>> Claim header.
>> But as I said, we could offer an option to introduce an option to
>> ignore soap attributes or maybe all global attributes to cover for wsu
>> attributes as well.
>> How do you think?
> I definitely have a different view point.  With all the customers and use cases I've
dealt with, the Schema elements represent the domain model for the application.   In many
cases, that model isn't even under the control of the people writing the front end services.
  It completely represents the model of the data that is part of their application.   How
that data gets passed back and forth is not part of the concern of the people writing the
> The soap attributes are a transport specific thing.  It's something that only applies
when transferring that data over soap.   It should not have any affect on the appearance of
the objects within the application domain.
> The soap spec specifically allows adding attributes onto these elements.   Thus, the
soap layer needs to handle the cases where the transport layers start polluting the data with
extra information that is not applicable to the domain model.   For this specific case, it
include the mustUnderstand and actor/role things.   However, it can also be the wsu:Id attribute
and others.
> As an example, if I have an existing application up and running using normal basic auth
or similar.  However, we now want to add ws-security stuff to sign the headers.   That's an
administrator/security domain thing and that shouldn't impact the application level objects
and schema.   They shouldn't have to go back and add attributes onto the various objects to
get the validation that was working fine to work again.
> Anyway, for the most part, most people that I've encountered do not want the soap spec
stuff to pollute their domain models.  However, we also need to be able to accept requests
that have that mustUnderstand attribute on them as the soap spec requires that.   Thus,  I
think the current behavior is closer to "correct".   One thought is that we could look at
the schema (we have it in the XmlSchemaCollection stuff) to see if the root element has some
extensibility or restriction capabilities on it for the attributes and use a scaled down error
handler in those cases.  Just a bit more work to do.

Hi Dan,
I think we actually have the same view.  I absolutely agree with you
that the domain model should not be concerned with some external
extensions like soap, ws, etc or any future unknown out-of-the-band
extensions. And that is the reason why the schema spec provided
<xs:anyAttribute namespace="##other"/> that allows you to use those
external extensions with your domain model without your domain model
needing to know of those extensions. Many standard schemas as well as
CXF's own config schemas are utilizing the anyAttribute wildcards in
this way.

Unfortunately, there is a shortcoming with this any-attribute
mechanism. Namely, some existing schemas may not have it. In addition,
it is cumbersome  to include the any-attribute everywhere where you
want to expect external extensions.

To overcome this shortcoming, CXF can offer an option to assume at the
validation that every element has implicitly <xs:anyAttribute
namespace="##other"/> declaration. If the original schema has some
"forbid" or "required" global attribute declarations, we should honor
these rules. But when we find a global attribute which is not declared
in the schema, we can accept it even if the schema does not include
the any-attribute declaration. This behavior is not specific to soap.
So if CXF is to support wsu:Id or some other existing or future
external extensions while using the schema which does not include the
any-attribute decls, we can handle these attributes as well
automatically. We can decide if this behavior is by default or
optional. In this way, we can have a generic and flexible validation
mechanism to support both strict and generous validation. I think this
idea is not contradicting to your view.

By the way, while thinking on this, I wished that XMLSchema included a
schema-level option to say <anyAttribute> is included everwhere. So
you can write something like


If this was there, people might have used it and we wouldn't have run
into this issue.

But this is another topic.

regards, aki

> Dan
>> aki
>> 2013/2/19 Daniel Kulp <>:
>>> I just made some more changes to this that will hopefully work a bit better.
>>> Basically, rather than remove the attributes from the Element, I stick an error
handler onto the Schema validator to ignore the errors related to the mustUnderstand and Actor/Role
attributes that SOAP clients may stick on the headers.   Thus, if your schema does have them,
JAXB should then be able to read them and populate the values but they won't generate validation
errors if they are there.
>>> Can you give that a try to see if that then works for your use case?
>>> Dan
>>> On Feb 18, 2013, at 10:12 AM, Jesus Castillo <>
>>>> Hi Dan,
>>>> For now, I disabled the validation of the attribute as a workaround until
>>>> final solution is found.
>>>> However, as this attribute is part of the schema defining the custom header,
>>>> I expect to retrieve it
>>>> too. In a perfect world, you shouldn't remove this attribute at all as this
>>>> is or should be part of the
>>>> custom schema if needed. So, if you are to remove it, I think this solution
>>>> should be the exception
>>>> and not the rule.
>>>> Rgds,
>>>> Jesus.
>>>> --
>>>> View this message in context:
>>>> Sent from the cxf-user mailing list archive at
>>> --
>>> Daniel Kulp
>>> -
>>> Talend Community Coder -
> --
> Daniel Kulp
> -
> Talend Community Coder -

View raw message