On Feb 20, 2013, at 5:30 AM, Aki Yoshida <[email protected]> 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: > http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html#annotation > > 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 model. 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. Dan > > aki > > 2013/2/19 Daniel Kulp <[email protected]>: >> >> 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 <[email protected]> >> wrote: >> >>> Hi Dan, >>> >>> For now, I disabled the validation of the attribute as a workaround until a >>> 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: >>> http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html >>> Sent from the cxf-user mailing list archive at Nabble.com. >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
