Return-Path: X-Original-To: apmail-axis-java-user-archive@www.apache.org Delivered-To: apmail-axis-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 31CE39C35 for ; Thu, 10 Nov 2011 18:12:59 +0000 (UTC) Received: (qmail 64607 invoked by uid 500); 10 Nov 2011 18:12:57 -0000 Delivered-To: apmail-axis-java-user-archive@axis.apache.org Received: (qmail 64499 invoked by uid 500); 10 Nov 2011 18:12:57 -0000 Mailing-List: contact java-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@axis.apache.org Delivered-To: mailing list java-user@axis.apache.org Received: (qmail 64491 invoked by uid 99); 10 Nov 2011 18:12:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2011 18:12:57 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [194.40.127.85] (HELO C005895.axa.ch) (194.40.127.85) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2011 18:12:47 +0000 X-IronPort-AV: E=Sophos;i="4.69,489,1315173600"; d="scan'208,217";a="50550960" Received: from c005812.chres1.doleni.net ([194.40.60.24]) by C005895.ch.winterthur.com with ESMTP; 10 Nov 2011 19:12:27 +0100 Received: from c005815.chres1.doleni.net ([194.40.60.9]) by c005812.chres1.doleni.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 19:12:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9FD4.4D695F99" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [axis2] migrating axis2-1.2 to axis2-1.6.1 actionMapping Problem Date: Thu, 10 Nov 2011 19:12:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [axis2] migrating axis2-1.2 to axis2-1.6.1 actionMapping Problem Thread-Index: Acyfv8ZH7zvsduoWR+SNVYDmKIhXowAEAFHQ References: From: "Stadelmann Josef" To: X-OriginalArrivalTime: 10 Nov 2011 18:12:26.0737 (UTC) FILETIME=[4D66D610:01CC9FD4] X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01CC9FD4.4D695F99 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Martin =20 I am not having a WSDL;=20 =20 By default an Axis2-1.2-server when set with the service.xml as shown = below, without an defined returns for an = urn:login urn:login in the soap response = header. But an Axis2-1.6.1-server returns by default urn:loginResponse = in its soap response header. =20 Adding urn:login to = servioce.xml overrides this default behaviour to return urn:login, what = my .NET WCF client stub expects. The client stub can be generated to expect urn:loginResponse, but all = must match. =20 The thing I am wondering is how to do the same by coding at the service. = BUT this is not important for the moment as my clinet works and as it = gets always urn:login back from regardless if Axis2-1.2 or Axis2-1.6.1 = is engaged. =20 Josef =20 The service.xml can do it . . . =20 SpezplaService with login, fktmap and logout using = Apache Axis2/Java axawl.spezpla.servers.SpezplaService.SpServer urn:login urn:login urn:fktmap urn:fktmap urn:logout urn:logout =20 Von: Martin Gainty [mailto:mgainty@hotmail.com]=20 Gesendet: Donnerstag, 10. November 2011 16:45 An: java-user@axis.apache.org; axis-user@ws.apache.org Betreff: RE: [axis2] migrating axis2-1.2 to axis2-1.6.1 actionMapping = Problem =20 Josef.wsdl: =20 ............=E4ndern Sie zu................ Mit Freuendlichen Gruben Martin=20 ______________________________________________=20 Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene = Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede = unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. = Diese Nachricht dient lediglich dem Austausch von Informationen und = entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten = Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt = uebernehmen. =20 ________________________________ Subject: [axis2] migrating axis2-1.2 to axis2-1.6.1 actionMapping = Problem Date: Thu, 10 Nov 2011 15:16:18 +0100 From: josef.stadelmann@axa-winterthur.ch To: axis-user@ws.apache.org I migrated my web service from axis2-1.2 to axis2-1.6.1 and have the = following anomalie now: There are 3 methodes Login Fktmap Logout Resulting in a=20 Action urn:login, urn:fktmap urn:logout As a response from axis2-1.2 I got always urn:login = urn:fktmap urn:logout As a response from axis2-1.6.1 I get new urn:loginResponse = urn:fktmapResponse urn:logoutResponse So that has changed from axis2-1.2 to axis2-1.6.1 what ever is correct I = don't mind !!!=20 For me the interface between the two has changed dramatically with a for = us very unplesant side effect which we don't know how to handle at the = moment. Because: My client is a Visual Basic .NET with transport dlls in Visual C#.NET = based on WCF 3.5 The generated stub expects urn:login and urn:login with the response = too. But now gets urn:loginResponse instead adding "Response" to all = action elements And fails to deliver ofcourse. I have fixed my stub to expect for a urn:login action a urn:loginRespons = action back and that works BUT - we have a lot of operating servers and we have only 3 client codse = release cycles per year! We have now old axis2-1.2 based services behaviour which deliver = urn:login action for Request and Response And we have new axis2-1.6.1 based behaviour which concatenates to each = request action code the word Response on a return from server. =20 I can not reconstruct my client to deal with 2 DLL's one expecting = urn:login the orther expecting urn:loginRespons as action back from = server. =20 Question: How can I prevent Axis2-1.6.1, from returning urn:loginResponse but = retruning urn:login only NOTE: no WSDL was used for code generation at all, all is just java = coded using OMElement very much as the examples in axis2 samples do. =20 Josef ------_=_NextPart_001_01CC9FD4.4D695F99 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [axis2] migrating axis2-1.2 to axis2-1.6.1 = actionMapping Problem

Thank you = Martin

 

I am not = having a WSDL;

 

By default = an Axis2-1.2-server when set with the service.xml as shown below, = without an <outputActionMapping> defined = returns for an <actionMapping>urn:login</actionMapping> = urn:login in the soap = response header. But an Axis2-1.6.1-server returns by default = urn:loginResponse in its soap response = header.

 

Adding = =A0<outputActionMapping>urn:login</outputAc= tionMapping> to servioce.xml overrides this default = behaviour to return urn:login, what my .NET WCF client stub = expects.

The client = stub can be generated to expect urn:loginResponse, but all must = match.

 

The thing I = am wondering is how to do the same by coding at the service. BUT this is = not important for the moment as my clinet works and as it gets always = urn:login back from regardless if Axis2-1.2 or Axis2-1.6.1 is = engaged.

 

Josef

 

The service.xml can do it . . .

 

<serviceGroup>

=A0=A0=A0 <service name=3D"SpezplaService" = scope=3D"soapsession">

=A0=A0=A0=A0=A0=A0=A0 <description>SpezplaService with login, = fktmap and logout using Apache = Axis2/Java</description>

=A0=A0=A0=A0=A0=A0=A0 <module = ref=3D"addressing"/>

=A0=A0=A0=A0=A0=A0=A0 <parameter name=3D"ServiceClass" = locked=3D"false">axawl.spezpla.servers.SpezplaService.SpServ= er</parameter>

=A0=A0=A0=A0=A0=A0=A0 <operation = name=3D"login">

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <messageReceiver = class=3D"org.apache.axis2.receivers.RawXMLINOutMessageReceiver"= />

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= ;actionMapping>urn:login</actionMapping>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <outputActionMapping>urn:login</outputActionMapping>

=A0=A0=A0=A0=A0=A0=A0 </operation>

=A0=A0=A0=A0=A0=A0=A0 <operation = name=3D"fktmap">

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <messageReceiver = class=3D"org.apache.axis2.receivers.RawXMLINOutMessageReceiver"= />

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= ;actionMapping>urn:fktmap</actionMapping>

<= p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <outputActionMapping>urn:fktmap</outputActionMapping>

=A0=A0=A0=A0=A0=A0=A0 </operation>

=A0=A0=A0=A0=A0=A0=A0 <operation = name=3D"logout">

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <messageReceiver = class=3D"org.apache.axis2.receivers.RawXMLINOutMessageReceiver"= />

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= ;actionMapping>urn:logout</actionMapping>

<= p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <outputActionMapping>urn:logout</outputActionMapping>

=A0=A0=A0=A0=A0=A0=A0 </operation>

=A0=A0=A0 </service>

</serviceGroup>

 

Von:<= /b> Martin = Gainty [mailto:mgainty@hotmail.com]
Gesendet: Donnerstag, 10. = November 2011 16:45
An: java-user@axis.apache.org; = axis-user@ws.apache.org
Betreff: RE: [axis2] migrating = axis2-1.2 to axis2-1.6.1 actionMapping = Problem

 

Josef.wsdl:<= br> 
<wsdl:operation name=3D"handleStringArray" = parameterOrder=3D"input">
   <wsdl:inpu= t name=3D"handleStringArrayRequest" = message=3D"impl:handleStringArrayRequest"/>
  &= nbsp;<wsdl:output name=3D"handleStringArrayResponse" = message=3D"impl:handleStringArrayResponse"/>
  = </wsdl:operation>
<wsdl:message = name=3D"handleStringArrayResponse">
  <wsdl:= part name=3D"output" = element=3D"impl:outputElement"/>
 </wsdl:message&= gt;

............= =E4ndern Sie zu................

 <ws= dl:operation name=3D"handleStringArray" = parameterOrder=3D"input">
<wsdl:input = name=3D"handleStringArrayRequest" = message=3D"impl:handleStringArrayRequest"/>
<wsdl:outp= ut name=3D"handleStringArrayResponse" = message=3D"impl:handleStringArray= "/>
</wsdl:operation>
<wsdl:message = name=3D"handleStringArray">
  <wsdl:part name=3D"output" = element=3D"impl:outputElement"/>
 </wsdl:message&= gt;

Mit Freuendlichen Gruben
Martin =
______________________________________________
Verzicht und = Vertraulichkeitanmerkung

Diese Nachricht ist vertraulich. Sollten = Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um = eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie = ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von = Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund = der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung = fuer den Inhalt uebernehmen.
 

Subject: = [axis2] migrating axis2-1.2 to axis2-1.6.1 actionMapping = Problem
Date: Thu, 10 Nov 2011 15:16:18 +0100
From: = josef.stadelmann@axa-winterthur.ch
To: = axis-user@ws.apache.org

I migrated = my web service from axis2-1.2 to axis2-1.6.1 and have the following = anomalie now:<= /span>

There are 3 = methodes<= /span>

Login<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><= /span>

Fktmap= <= /span>

Logout= <= /span>

Resulting in = a <= /span>

Action = urn:login, urn:fktmap urn:logout<= /span>

As a = response from axis2-1.2    I  got always = urn:login          &nbs= p;           = urn:fktmap          &nb= sp;           &nbs= p;   urn:logout<= /span>

As a = response from axis2-1.6.1 I  get new     = urn:loginResponse        = urn:fktmapResponse         &= nbsp; urn:logoutResponse<= /span>

So that has = changed from axis2-1.2 to axis2-1.6.1 what ever is correct I don’t = mind !!! <= /span>

For me the = interface between the two has changed dramatically with a for us very = unplesant side effect which we don’t know how to handle at the = moment.<= /span>

Because:<= /span>

My client is = a Visual Basic .NET with transport dlls in Visual C#.NET based on WCF = 3.5<= /span>

The = generated stub expects urn:login and urn:login with the response too. = But now gets urn:loginResponse instead adding "Response" to = all action elements<= /span>

And fails to = deliver ofcourse.<= /span>

I have fixed = my stub to expect for a urn:login action a urn:loginRespons action back = and that works<= /span>

BUT – = we have a lot of operating servers and we have only 3 client codse = release cycles per year!<= /span>

We have now = old axis2-1.2 based services behaviour which deliver urn:login action = for Request and Response<= /span>

And we have = new axis2-1.6.1 based behaviour which concatenates to each request = action code the word Response on a return from server.<= /span>

 <= /o:p>

I can not = reconstruct my client to deal with 2 DLL's one expecting urn:login the = orther expecting urn:loginRespons as action back from = server.<= /span>

 <= /o:p>

Question:<= /span>

How can I = prevent Axis2-1.6.1, from returning urn:loginResponse but retruning = urn:login only<= /span>

NOTE: no = WSDL was used for code generation at all, all is  just java coded = using OMElement very much as the examples in axis2 samples = do.<= /span>

 <= /o:p>

Josef<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><= /span>

------_=_NextPart_001_01CC9FD4.4D695F99--