Return-Path: X-Original-To: apmail-cxf-issues-archive@www.apache.org Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 148B717AFE for ; Thu, 5 Nov 2015 10:56:28 +0000 (UTC) Received: (qmail 19741 invoked by uid 500); 5 Nov 2015 10:56:27 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 19704 invoked by uid 500); 5 Nov 2015 10:56:27 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 19681 invoked by uid 99); 5 Nov 2015 10:56:27 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Nov 2015 10:56:27 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id A92E02C14DC for ; Thu, 5 Nov 2015 10:56:27 +0000 (UTC) Date: Thu, 5 Nov 2015 10:56:27 +0000 (UTC) From: "Christopher Leung (JIRA)" To: issues@cxf.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CXF-6666) Permit "unknown" SOAP message header elements and attributes to prevent Unmarshalling Error: unexpected element MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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 DataReader createReader(Class c) { DataReader 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)