Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BC1A010230 for ; Wed, 28 Aug 2013 08:31:39 +0000 (UTC) Received: (qmail 50834 invoked by uid 500); 28 Aug 2013 08:31:38 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 50629 invoked by uid 500); 28 Aug 2013 08:31:37 -0000 Mailing-List: contact dev-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 dev@cxf.apache.org Received: (qmail 50621 invoked by uid 99); 28 Aug 2013 08:31:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Aug 2013 08:31:36 +0000 X-ASF-Spam-Status: No, hits=4.0 required=5.0 tests=FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of zxzxzczz@163.com designates 220.181.13.121 as permitted sender) Received: from [220.181.13.121] (HELO m13-121.163.com) (220.181.13.121) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Aug 2013 08:31:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=lwcTYU/GiRsugmGQcHILMdkMKzK1o3Dg9K4m h9E3zxE=; b=o+K05f7qeegWJt/EFTt8Muxfa+qE7n1OyLecIjawR6Sv/XUXvmpI u0lJ+/7O9tz3GQqUQRgaWiDl6aeaAtT9Bc71HHJgPv3cropZTrWwgN3HkPFUXs5C cA4uicqQWrTAuX2n6HEyWkhNWgd+qaFctTQx1uoVGu3wkCsmJIBSZBI= Received: from zxzxzczz$163.com ( [1.202.240.210] ) by ajax-webmail-wmsvr121 (Coremail) ; Wed, 28 Aug 2013 16:31:05 +0800 (CST) X-Originating-IP: [1.202.240.210] Date: Wed, 28 Aug 2013 16:31:05 +0800 (CST) From: alex To: dev@cxf.apache.org Subject: Issue: operation level policy attachment and BindingOperationInfo X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20130709(22708.5479.5480) Copyright (c) 2002-2013 www.mailtech.cn 163com X-CM-CTRLDATA: RJqpG2Zvb3Rlcl9odG09Mzg3MDo4MQ== Content-Type: multipart/mixed; boundary="----=_Part_376057_1449019071.1377678665125" MIME-Version: 1.0 Message-ID: <97070ea.19768.140c40c25a6.Coremail.zxzxzczz@163.com> X-CM-TRANSID: ecGowEDpbEFKtR1S8wkLAA--.2605W X-CM-SenderInfo: h20256xf22qiywtou0bp/1tbiOwGG3FEAG69EBgACsF X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_376057_1449019071.1377678665125 Content-Type: multipart/alternative; boundary="----=_Part_376059_1238251018.1377678665126" ------=_Part_376059_1238251018.1377678665126 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi, We are seeing some policy attachment issues when policies are attached to both service and operation level. While we expect operation level policy UserNameToken2 should be applied to server inbound, we are surprised to find out this is not always the case. When running the same test case again and again, we found UserNameToken2 is applied in one run, and UserNameToken1 is applied in another run. Which policy is applied is totally random. Further debug, we found out that there are two BindingOperationInfo instances in server inbound. [8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo: {http://mustunderstand.cxf.fats}invoke]:0 [8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O PolicyInInterceptor():debugBoi:[BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo: {http://mustunderstand.cxf.fats}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@8c2760ba:outMessage:org.apache.cxf.service.model.BindingMessageInfo@33f92db2 [8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo: {http://cxf.apache.org/jaxws/provider}invoke]:1 [8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O PolicyInInterceptor():debugBoi:[BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo: {http://cxf.apache.org/jaxws/provider}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@b72a33df:outMessage:org.apache.cxf.service.model.BindingMessageInfo@34105618 One instance is created from WSDL with namespace {http://mustunderstand.cxf.fats}invoke], and another is hardcoded namespace http://cxf.apache.org/jaxws/provider. Depending on the order of instances, if instance from WSDL is first, operation policy is applied as expected. If instance with default JAXWS namespace is first, operation policy is NOT applied. Looking at JaxWsServiceFactoryBean.java, line 355 to 385, I can see BindingOperationInfo is always created with JAXWS namespace regardless WSDL. Could someone help to explain why we need two instances of BindingOperationInfo? and why this impact policy attachment? ------=_Part_376059_1238251018.1377678665126 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
Hi,
We are seeing some policy attachment issues when policies are attached to both service and operation level.
 <wsdl:binding name="UrnMustUnderstandBinding2" type="tns:MustUnderstand">
        <wsp:PolicyReference URI="#UserNameToken1" />
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="invoke">
            <soap:operation soapAction="" style="document"/>
            <wsdl:input name="getVerRequest">
                <soap:body use="literal"/>
                 <wsp:PolicyReference URI="#UserNameToken2" />
            </wsdl:input>    
            <wsdl:output name="getVerResponse">
               <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>        
    </wsdl:binding>

While we expect operation level policy UserNameToken2  should be applied to server inbound, we are surprised to find out this is not always the case. When running the same test case again and again, we found  UserNameToken2 is applied  in one run, and UserNameToken1 is applied in another run. Which policy is applied is totally random.

Further debug, we found out that there are two BindingOperationInfo instances in server inbound.
[8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo: {http://mustunderstand.cxf.fats}invoke]:0
[8/27/13 12:43:37:629 CDT] 00000034 id= SystemOut O PolicyInInterceptor():debugBoi:[BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo: {http://mustunderstand.cxf.fats}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@8c2760ba:outMessage:org.apache.cxf.service.model.BindingMessageInfo@33f92db2

[8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O PolicyInInterceptor():BindingOperationInfo:[BindingOperationInfo: {http://cxf.apache.org/jaxws/provider}invoke]:1
[8/27/13 12:43:37:630 CDT] 00000034 id= SystemOut O PolicyInInterceptor():debugBoi:[BindingInfo http://schem as.xmlsoap.org/wsdl/soap/]:OperationInfo:[OperationInfo: {http://cxf.apache.org/jaxws/provider}invoke]:input:org.apache.cxf.service.model.BindingMessageInfo@b72a33df:outMessage:org.apache.cxf.service.model.BindingMessageInfo@34105618
One instance is created from WSDL with namespace {http://mustunderstand.cxf.fats}invoke], and another is hardcoded namespace http://cxf.apache.org/jaxws/provider.
Depending on the order of instances, if instance from WSDL is first, operation policy is applied as expected. If instance with default JAXWS namespace is first, operation policy is NOT applied.
Looking at JaxWsServiceFactoryBean.java, line 355 to 385, I can see BindingOperationInfo is always created with JAXWS namespace regardless WSDL.
Could someone help to explain why we need two instances of BindingOperationInfo? and why this impact policy attachment?


------=_Part_376059_1238251018.1377678665126-- ------=_Part_376057_1449019071.1377678665125--