glassfish
  1. glassfish
  2. GLASSFISH-17367

Default JMS host ist set to "localhost", which cannot be resolved by appclient

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.2_b08
    • Component/s: jms
    • Labels:
      None
    • Environment:

      Win7 Pro SP1 64 Bit

      Description

      glassfish-3.1.1-windows creates a default domain (domain1), which contains the following line:

      <jms-host name="default_JMS_host" host="localhost" port="7676" admin-user-name="admin" admin-password="admin" lazy-init="true"/>

      The problem is the word "localhost", as it gets transferred to remote appclients in an unchanged way. As soon as a client program running in ACC tries to start a JMS connection, it will fail as it tries to reach "localhost".

      Obviously, the ACC should get provided the JMS server's real hostname by the server instead of "localhost", or even better, the actual IP address to which the JMS port is currently bound.

        Activity

        Hide
        scatari added a comment -

        We could document this, given that the none of the configuration exists for "zip" based installer. I am transferring to admin backend team to see if they can replace "localhost" with the IP address.

        Show
        scatari added a comment - We could document this, given that the none of the configuration exists for "zip" based installer. I am transferring to admin backend team to see if they can replace "localhost" with the IP address.
        Hide
        scatari added a comment -

        Snjezana, Please work with admin team to identify the owner for this issue.

        Show
        scatari added a comment - Snjezana, Please work with admin team to identify the owner for this issue.
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

        Assigning to Tom and cc-ing Tim to get further input. While "localhost" needs to remain in the initial default domain shipped in zip distribution in order to make the configuration portable, maybe it would be possible to replace it with fully qualified hostname prior to the point where configuration gets used by remote appclient.

        Show
        Snjezana Sevo-Zenzerovic added a comment - Assigning to Tom and cc-ing Tim to get further input. While "localhost" needs to remain in the initial default domain shipped in zip distribution in order to make the configuration portable, maybe it would be possible to replace it with fully qualified hostname prior to the point where configuration gets used by remote appclient.
        Hide
        Tom Mueller added a comment -

        This looks like something that the ACC needs to handle.

        Show
        Tom Mueller added a comment - This looks like something that the ACC needs to handle.
        Hide
        Tim Quinn added a comment -

        I disagree that this is the responsibility of the ACC.

        [The rest of this notes is IIRC - I am not very familiar with what happens internally in this process... ] One of the first steps a JMS client performs is to obtain a ConnectionFactory, either by explicit look-up using JNDI calls or by injection which itself will use JNDI look-up. The factory object will have been set up to refer to whatever host is specified in the jms-host setting. If that is localhost, then that is how the factory object will be set up, and that is what the client will get.

        I think the documentation refers, at least briefly, to the need to configure the jms host's address to refer to the host's actual address if it will be used remotely. But I'm not sure about that.

        I'm transferring this to the queuing folks, not because I think there is a bug in JMS or MQ that needs fixing but for them to comment on this.

        One other note - Aren't there potential problems if somehow GlassFish did automatically place the system's real name into this configuration setting and then the user tries to run disconnected from the network? I think the attempt to resolve the configured, non-"localhost" name will fail because the system cannot reach a DNS server.

        Show
        Tim Quinn added a comment - I disagree that this is the responsibility of the ACC. [The rest of this notes is IIRC - I am not very familiar with what happens internally in this process... ] One of the first steps a JMS client performs is to obtain a ConnectionFactory, either by explicit look-up using JNDI calls or by injection which itself will use JNDI look-up. The factory object will have been set up to refer to whatever host is specified in the jms-host setting. If that is localhost, then that is how the factory object will be set up, and that is what the client will get. I think the documentation refers, at least briefly, to the need to configure the jms host's address to refer to the host's actual address if it will be used remotely. But I'm not sure about that. I'm transferring this to the queuing folks, not because I think there is a bug in JMS or MQ that needs fixing but for them to comment on this. One other note - Aren't there potential problems if somehow GlassFish did automatically place the system's real name into this configuration setting and then the user tries to run disconnected from the network? I think the attempt to resolve the configured, non-"localhost" name will fail because the system cannot reach a DNS server.
        Hide
        Satish Kumar added a comment -

        The value of jms-host.host is defaulted to localhost so that it can work with the zip installer. Automatically setting this to the actual hostname is not recommended as Tim has also pointed out. A note to the effect that the user will need to manually configure this if required, is mentioned in the documentation.

        Show
        Satish Kumar added a comment - The value of jms-host.host is defaulted to localhost so that it can work with the zip installer. Automatically setting this to the actual hostname is not recommended as Tim has also pointed out. A note to the effect that the user will need to manually configure this if required, is mentioned in the documentation.
        Hide
        mkarg added a comment -

        I have to object. This issue is not talking about ZIP bundles but about solely the Windows Installer bundle. In the Windows world, people are used to get jumpstart defaults instead of reading docs since the installer is an active software that can use the complete Windows API - including the functions for checking hostnames and changing XML files. Please forget (just for one minute) all your technical constraints and watch the scene from the administrator's view. After having run the windows installer, you force him to fiddle with the JMS settings to manually provide the host name - yes, of exactly that host that just did run the installer. And, EVERYONE does that in THE EXACTLY SAME WAY. My goodness, why shall it be so impossible for the installer to just do that automatically? I mean, is it so unbelievable hard to change the installer code in a way that just replaces localhost by %HOSTNAME%? Sorry, but this is just ridiculous. I do not see anything "invalid" in this bug report and expect a solution in the next release to stop all the GF competitors out there from loughing out loudly!

        Show
        mkarg added a comment - I have to object. This issue is not talking about ZIP bundles but about solely the Windows Installer bundle. In the Windows world, people are used to get jumpstart defaults instead of reading docs since the installer is an active software that can use the complete Windows API - including the functions for checking hostnames and changing XML files. Please forget (just for one minute) all your technical constraints and watch the scene from the administrator's view. After having run the windows installer, you force him to fiddle with the JMS settings to manually provide the host name - yes, of exactly that host that just did run the installer. And, EVERYONE does that in THE EXACTLY SAME WAY. My goodness, why shall it be so impossible for the installer to just do that automatically? I mean, is it so unbelievable hard to change the installer code in a way that just replaces localhost by %HOSTNAME%? Sorry, but this is just ridiculous. I do not see anything "invalid" in this bug report and expect a solution in the next release to stop all the GF competitors out there from loughing out loudly!

          People

          • Assignee:
            Satish Kumar
            Reporter:
            mkarg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: