Bug 384236

here is the small server snippet that we use as WebMethod in ZMD.



using System;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.ComponentModel;
using Novell.Zenworks.Utility;
using Novell.Zenworks.Zmd;
using Novell.Zenworks.Zmd.Public;
using log4net; 

namespace Novell.Zenworks.Zmd.Remote {

    [Module]
    public class Server {

        public static ModuleInfo ModuleInit () {
            return new ModuleInfo ("ZENworks Server",
                                   "Novell, Inc",
                                    GettextCatalog.GetString ("SOAP methods used by a ZENworks server"),
                                   "GPL");
        }

        [WebMethod, Privilege ("view")]
        public string Ping () {
            return String.Format ("pong");
        }
    }
}

The wsdl that is used to call this is pasted below.





/// <remarks/>
[System.Web.Services.WebServiceBinding(Name="ServerSoap", Namespace="http://tempuri.org/")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
public class Server : System.Web.Services.Protocols.SoapHttpClientProtocol {

    public Server() {
        this.Url = "http://localhost:5505/zmd/Server.asmx";
    }

    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Ping", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped, Use=System.Web.Services.Description.SoapBindingUse.Literal)]
    public string Ping() {
        object[] results = this.Invoke("Ping", new object[0]);
        return ((string)(results[0]));
    }
}

The Client throws


HTTP 404 not Found and sometimes 401 Unauthorized(very rare).

. 

For 401 issue we need concrete procedure to reproduce the issue (not always necessarily to be reproductive but with certain hints to do it are expected). Revisit here with independent bug report.

For 404 -> duplicate.

*** This bug has been marked as a duplicate of bug 371859 ***

Note: 

15:52:36 abacusv     Hmm the path patch you suggested does it work

The code is picked from ZMD as a test snippet.

from #mono

16:05:41 eno         abacusv: actually, are you using remoting?
16:05:50 eno         [WebMethod] has nothing to do with it
16:06:43 abacusv     Yes
16:07:02 eno         Then it's a remoting issue, not about WebServices
16:08:01 eno         Did you really get it working when you applied my patch?
16:09:27 abacusv     NOpe I dint apply your patch.
16:09:52 eno         oh?
16:09:55 eno         is confused

Marek, any idea why it's getting 404?

using System;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.ComponentModel;

namespace Novell.Zenworks.Zmd.Remote {

    public class Server {

        [WebMethod]
        public string Ping () {
            return String.Format ("pong");
        }
    }
}

Main Program

using System;

class pingSoap {

    public static void Main(string [] args) {

        // Your license key

        // Create a Google Search object
        Server Service1 = new Server();

        // Ask for spelling suggestion
        // The first argument is your key
        // The second one, the text the user should enter.

        Console.WriteLine("Response {0}", Service1.Ping()) ;
    }
}



<%@ WebService Language="C#" Class="Server" %>

the above line should be placed in the tomcat root directory.

Since the application is bit complex we could provide you the setup that can be used to reproduce the issue with the source.

PS: ZMD is shipped by default with SLE10 platforms.

stack trace from the working mono version 1.2.2

http://164.99.96.41:2544/zmd/Server.asmx

<!--
System.Web.HttpException:  ---&gt; System.ArgumentNullException: Argument cannot be null.
Parameter name: path1
  at System.IO.Path.Combine (System.String path1, System.String path2) [0x00000] 
  at System.Web.Compilation.BaseCompiler.GetCompiledType () [0x00000] 
  at System.Web.Compilation.AspGenerator.GetCompiledType () [0x00000] 
  at System.Web.UI.PageParser.CompileIntoType () [0x00000] 
  at System.Web.UI.TemplateControlParser.GetCompiledInstance () [0x00000] 
  at System.Web.UI.PageParser.GetCompiledPageInstance (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) [0x00000] 
  at System.Web.Services.Protocols.SoapDocumentationHandler..ctor (System.Type type, System.Web.HttpContext context) [0x00000] 
  at System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler (System.Web.HttpContext context, System.String verb, System.String url, System.String filePath) [0x00000] 
  at System.Web.HttpApplication.GetHandler (System.Web.HttpContext context) [0x00000] 
  at System.Web.HttpApplication+&lt;&gt;c__CompilerGenerated2.MoveNext () [0x00000] --- End of inner exception stack trace ---

-->

after upgrading mono 1.9.1

<![CDATA[
System.Web.HttpException: File not found: Server.asmx
]]>

Does the Server.asmx file physically exist in the location?

Yes it does.


/usr/share/zmd/SOAP/Server.asmx

To recap an IRC conversation and make the issue a bit clear.

The erorr from comment 11 above is the _desired_ behavior for zmd - it relies upon this error and breaks on the _fixed_ behavior of sending the 404 in the later versions.

Created attachment 211151 [details]
Autogenerated from Server.wsdl 

SOAP stub that calls the WebMethod exposed by ZMD

Created attachment 211152 [details]
soap client that calls the server stubs. (Main program)

the above attachments are the soap client test programs which calls the WebMethod exposed by ZMD.

Use the attached files to compile pingSoap.exe 

Compiling the code.

mcs pingSoap.cs Server.cs -r:System.Web.Services 


The expected output is "Response pong". Works fine with zmd running on mono v 1.2.2 or 1.2.5 

We get 
Unhandled Exception: System.Net.WebException: The request failed with HTTP status 404: NotFound

after upgrading mono to 1.2.6 or above.

The issue was caused by a bug in zmd source. The attached patch fixes the problem.

Created attachment 211170 [details]
worker.diff

I consider the bug fixed with the above diff.

Agree to the above suggestion and verified.

hence closing the defect