• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

my webservice supports Axis1.x but not Axis2.x ,so is it the compatibility issue?

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have one web service and i want to test whether it supports Axis1.x and Axis2.x or not?

I tried to create the stubs classes using Axis 2-1.2 , the stubs classes are generated successfully. But when I used this
stubs classes in my client side code and sent the soap request to one service method ,
I

It returned me an error

"run rg.apache.axis2.AxisFault: Transport: Unable to parse XML
input

document
no element found at line 1, column 0, byte -1 at
/postini/e4_0_0c0/lib/perl5/site_perl/5.8.8/i686-linux/XML/Parser.pm
line 187"

So i used lower version of Axis 1.3.0 and generated stubs from wsdl file and used that stubs in my client side code.when i sent the request to one of the service method i get the correct response from web service.

so could you guys please let me know whether this is the versioning issue.please share your knowledge on the same.
But i am just wondering if my web service supports Axis1 it should be compatible with Axis2.

I also observed that the stubs classes created using Axis2 and Axis1 are totally different ,i guess it would be different ways creating stubs for Axis 1 and Axis2,please share your thoughts if anyone knows more on it

Following ar 2 client side code(for stubs generated using Axis1 and Axis 2) that i used to call the service method.
********************************************************

Using stubs classes generated by Axis 1.3.0: which runs successfully
Note :returned output is of String type

try{
UserSyncService userSyncService=new UserSyncServiceLocator();
output=userSyncService.getUserSyncPort().test(true));
System.out.println(output);

}
catch(Exception ex)
{
ex.printStackTrace();
}


********************************************************
Using stubs classes created using Axis 2-1.2:

try{
UserSyncServiceStub stubClass=new UserSyncServiceStub();

UserSyncServiceStub.Test test=new UserSyncServiceStub.Test();
test.setShould_work(true);

UserSyncServiceStub.Test0 testo=new UserSyncServiceStub.Test0();
testo.setTest(test);

output=stubClass.test(testo);
System.out.println(output);

}
catch(Exception ex)
{
ex.printStackTrace();
}

It returned me an error

Your valuable suggestions will really help me.
Thanks In advance
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the case of diagnosing problems with SOAP web services the java code is usually of secondary importance. The most useful pieces of information are:
  • The WSDL
  • Any SOAP requests and responses sent as captured with Apache TCPMon(Tutorial) or java.net tcpmon.

  • Example topic.

    One big difference between Axis and Axis2: Axis2 does not support the RPC/encoded mode of messaging. (See Which style of WSDL should I use?). However I would have expected that it should have complained about that. Also Axis2 may make additional allowances for more recent interoperability enhancements that the Perl based web service isn't expecting.
     
    bhushan pawar
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Peer,
    you are right, my web services are developed in perl,but i am not sure whether the wsdl is RPC/encoded or RPC/literel as we are using the web services developed by third party(I read the link that you shared but by seeing from wsdl i cant predict whether it is RPC/encoded or RPC/literal,if you are aware how to recongnise it by observing wsdl only,could you please share your thoughts).
    Additional information about my webservice is i am successfully created the stubs using JAX-WS,Xmlbeans 2.2 and AXIS1.x and Axis2.X
    But only stubs created using Axis 2.X are responding with error message

    ""run rg.apache.axis2.AxisFault: Transport: Unable to parse XML
    input

    document
    no element found at line 1, column 0, byte -1 at
    /postini/e4_0_0c0/lib/perl5/site_perl/5.8.8/i686-linux/XML/Parser.pm
    line 187"
    "
    (Hope this information will helpful.)
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by bhushan pawar:
    if you are aware how to recongnise it by observing wsdl only,could you please share your thoughts.



    Thats what the article I linked to in my first reply explains: Which style of WSDL should I use?

    (Hope this information will helpful.)



    It is much more helpful to see the web service WSDL and the request/response (from both Axis 1. and Axis 2.x) as captured by Tcpmon (Apache TCPMon(Tutorial) or java.net tcpmon) that caused the problem (which I also mentioned in my first reply).

    The message simply states that the Perl module that parses the request choked on it. Now if you captured the "valid" request/response pair as it is generated/received by the Axis 1.x client and compare it to the request/response as generated/received by the Axis 2.x client and provided the WSDL that has used to generate those stubs - then there might be some hope in determining what went wrong and what you could do to fix it.

    I suspect that Axis 2.x is much more accurate about the interpretation of the WSDL and generates a request that is correct according to current standards. In that case it may be necessary to tweak the WSDL that you use to generate the stubs (if that in fact is still possible). To be able to make that tweak it is necessary to see a request/response pair that the Perl web service successfully processes (i.e. the one with the Axis 1.x stubs).
     
    And tomorrow is the circus! We can go to the circus! I love the circus! We can take this tiny ad:
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic