[jira] [Commented] (CXF-6666) Permit "unknown" SOAP message header elements and attributes to prevent Unmarshalling Error: unexpected element

["Christopher Leung (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-6666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991513#comment-14991513 ] 

Christopher Leung commented on CXF-6666:
----------------------------------------

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: Christopher Leung
>
> 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)