1 Reply Latest reply on Sep 15, 2008 10:53 PM by ron_sigal

    Who is responsible for setting the http.proxyHost

    adinn

      I'm running into a problem when trying to use a proxy with JBossWS (native 3.0.2 on AS 5.0.0.CR1). I have started my AS with -Dhttp.proxyHost=xxx and -Dhtttp.proxyPort=yyy on the command line. It turns out that the metadata that JBossWS passes to the remoting Client when trying to establish an HTTP connection for a Web Service invocation does not specify an http.proxyHost nor an http.proxyPort.

      So, who is responsible for detecting the system properties? I know the remoting code in HTTPClientInvoker used to look at these settings but it definitely does not do so now. Is this a bug introduced into remoting? Or is JBossWS (and, by implication, any other remoting client) now expected to check these system properties and ensure the metadata is appropriately configured?

      n.b. the system property settings do seem to be taken into account elsewhere in the AS. For example, if I don't supply them I have problems seeing the jsp index page which provides access to the service. If I do supply them I can see the jsp page, but still cannot access the web service.

        • 1. Re: Who is responsible for setting the http.proxyHost
          ron_sigal

           


          So, who is responsible for detecting the system properties? I know the remoting code in HTTPClientInvoker used to look at these settings but it definitely does not do so now. Is this a bug introduced into remoting? Or is JBossWS (and, by implication, any other remoting client) now expected to check these system properties and ensure the metadata is appropriately configured?


          HttpClientInvoker quit looking at the system properties "http.proxyHost" and "http.proxyPort" as of the changes made for JBREM-569 "HTTP(S) proxy broken". In fact, my understanding is that these system properties should be handled automatically by the Java runtime. See, for example, http://www.developer.com/java/other/article.php/1551421.

          Could you look further into what's really going on? Maybe run AS with TRACE logging turned on for Remoting in .../server/$CONFIG/conf/jboss-log4j.xml.