[
https://issues.apache.org/jira/browse/CXF-6666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991513#comment-14991513
]
Chris edited comment on CXF-6666 at 11/6/15 10:20 AM:
------------------------------------------------------
I failed to mention that in order to handle the binding of our custom SOAP
header to objects we employ the use of a custom
{{org.apache.cxf.headers.HeaderManager}}. This sets a {{HeaderProcessor}} which
in turn has configures our own {{DataBinding}} - lets call it
{{CustomHeaderDataBinding}} - which you can see below.
I've been able to access the {{DataReader}} and - in a rather convoluted way -
set the crucial "set-jaxb-validation-event-handler" property. This has solved
the issue but it's clearly working around some of the checks in DataReaderImpl.
{code}
public class CustomHeaderDataBinding extends JAXBDataBinding {
public CustomHeaderDataBinding() throws JAXBException {
super(CustomMessageHeaderObjectModel.class);
}
@Override
public <T> DataReader<T> createReader(Class<T> c) {
DataReader<T> dr = super.createReader(c);
Message message = PhaseInterceptorChain.getCurrentMessage();
if(message != null) {
message.setContextualProperty("set-jaxb-validation-event-handler", false);
dr.setProperty(org.apache.cxf.message.Message.class.getName(), message);
}
return dr;
}
}
{code}
This gets executed thanks to the following bit of code in
{{ReadHeadersInterceptor}}:
{code}
HeaderProcessor p = bus == null ? null : bus.getExtension(HeaderManager.class)
.getHeaderProcessor(hel.getNamespaceURI());
Object obj;
DataBinding dataBinding = null;
if (p == null || p.getDataBinding() == null) {
obj = hel;
} else {
dataBinding = p.getDataBinding();
obj = dataBinding.createReader(Node.class).read(hel);
}
{code}
The inflexibility here is with the following line:
{code}
obj = dataBinding.createReader(Node.class).read(hel);
{code}
The reader is created and the {{read()}} method called immediately. The only
way to influence this was by overriding the {{createReader()}} method as
illustrated above.
was (Author: chris573):
I failed to mention that in order to handle the binding of our custom SOAP
header to objects we employ the use of a custom
{{org.apache.cxf.headers.HeaderManager}}. This sets a {{HeaderProcessor}} which
in turn has configures our own {{DataBinding}} - lets call it
{{CustomHeaderDataBinding}} - which you can see below.
I've been able to access the {{DataReader}} and - in a rather convoluted way -
set the crucial "set-jaxb-validation-event-handler" property. This has solved
the issue but it's clearly working around some of the checks in DataReaderImpl.
{code}
public class CustomHeaderDataBinding extends JAXBDataBinding {
public CustomHeaderDataBinding() throws JAXBException {
super(CustomMessageHeaderObjectModel.class);
}
@Override
public <T> DataReader<T> createReader(Class<T> c) {
DataReader<T> dr = super.createReader(c);
Message message = PhaseInterceptorChain.getCurrentMessage();
if(message != null) {
message.setContextualProperty("set-jaxb-validation-event-handler", false);
dr.setProperty(org.apache.cxf.message.Message.class.getName(), message);
}
return dr;
}
}
{code}
This gets executed thanks to the following bit of code in
{{ReadHeadersInterceptor}}:
{code}
HeaderProcessor p = bus == null ? null : bus.getExtension(HeaderManager.class)
.getHeaderProcessor(hel.getNamespaceURI());
Object obj;
DataBinding dataBinding = null;
if (p == null || p.getDataBinding() == null) {
obj = hel;
} else {
dataBinding = p.getDataBinding();
obj = dataBinding.createReader(Node.class).read(hel);
}
{code}
> Permit "unknown" SOAP message header elements and attributes to prevent
> Unmarshalling Error: unexpected element
> ---------------------------------------------------------------------------------------------------------------
>
> Key: CXF-6666
> URL: https://issues.apache.org/jira/browse/CXF-6666
> Project: CXF
> Issue Type: Wish
> Components: JAXB Databinding, Soap Binding
> Affects Versions: 3.0.2
> Reporter: Chris
>
> How does one disable the strict validation on the *SOAP message header* that
> causes a "Unmarshalling Error: unexpected element" exception when unknown
> elements and attributes are encountered in the unmarshalling process. (In
> this case _unknown_ means that elements and attributes are present in the
> incoming SOAP header but do not exist in the object model.)
> The flow seems to be that
> [ReadHeadersInterceptor|https://cxf.apache.org/javadoc/latest/org/apache/cxf/binding/soap/interceptor/ReadHeadersInterceptor.html]
> creates a {{DataReader}} that creates an unmarshaller. The unmarshaller
> determines whether the custom {{ValidationEventHandler}},
> {{WSUIDValidationHandler}}, is set or not. {{WSUIDValidationHandler}} is
> ultimately responsible for throwing the exception.
> There appears to be a couple of ways at least to disable
> {{WSUIDValidationHandler}}. One is to set the {{setEventHandler}} flag of
> {{DataReaderImpl}} to false. The other is to ensure the {{veventHandler}}
> field of the same class is set to a more lenient custom
> {{ValidationEventHandler}}.
> I cannot determine a way in which to manipulate either of these two fields in
> {{DataReaderImpl}}. Is there a way to do it?
> {{setProperty(String prop, Object value)}} method of {{DataReaderImpl}} looks
> promising because it has lots of logic related to setting the
> ValidationEventHandler - in particular the
> {{set-jaxb-validation-event-handler}} property seems perfect - but
> unfortunately this method is not called when unmarshalling the SOAP header
> part, unless I'm mistaken.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
