glassfish
  1. glassfish
  2. GLASSFISH-18228

The OSGi Admin Console seems to randomly swap between port 8080 and 4848

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.2_b19, 4.0_b21
    • Component/s: OSGi
    • Labels:
      None
    • Status Whiteboard:
      Hide

      Workaround:
      In order to cause webconsole to bind to HTTP Service listen on 8080 (default http port), create a file called
      glassfish/domain1/autodeploy/bundles/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg
      with following content:
      http.service.filter=VirtualServer=server

      Show
      Workaround: In order to cause webconsole to bind to HTTP Service listen on 8080 (default http port), create a file called glassfish/domain1/autodeploy/bundles/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg with following content: http.service.filter=VirtualServer=server

      Description

      The OSGi Admin Console seems to randomly swap between port 8080 and 4848

      When running on 8080 it is accessible from the Server -> OSGi Console link under http://localhost:4848/

      However when it magically/randomly flips to running on 4848 the Server -> OSGi Console link returns a 404 error.

      I haven't done enough investigation to determine what is causing the port flipping. But it seems extremely strange that it happens at all.

      Off the top of my head (without any investigation), if two instances of HttpService are registered the ordering would be random and sometimes it gets the correct one and others it gets the wrong one... shrug

        Activity

        Hide
        aaronjwhiteside added a comment -

        Usually only the admin port is locked behind a firewall... and 8080 is mapped to 80 on the outside world. My point is it requires extra effort to block /osgi/* at the load balancer while allowing everything else through.

        If the default were to keep all the administration related functionality restricted to the admin port (4848) then we wouldn't need any extra configuration to block access to /osgi/*.

        Show
        aaronjwhiteside added a comment - Usually only the admin port is locked behind a firewall... and 8080 is mapped to 80 on the outside world. My point is it requires extra effort to block /osgi/* at the load balancer while allowing everything else through. If the default were to keep all the administration related functionality restricted to the admin port (4848) then we wouldn't need any extra configuration to block access to /osgi/*.
        Hide
        Sanjeeb Sahoo added a comment -

        I certainly don't understand why admin port is different from 8080 for an appserver. What advantage it has for an app server which is always behind firewall? Do you understand?

        Show
        Sanjeeb Sahoo added a comment - I certainly don't understand why admin port is different from 8080 for an appserver. What advantage it has for an app server which is always behind firewall? Do you understand?
        Hide
        aaronjwhiteside added a comment -

        I'll open a new issue, the point was I shouldn't have to be telling the OSGi console to run on the admin port. It should be doing that by default. Running an admin console even if it is OSGi's admin console on the normal application port (8080) is not a good idea, IMHO.

        Show
        aaronjwhiteside added a comment - I'll open a new issue, the point was I shouldn't have to be telling the OSGi console to run on the admin port. It should be doing that by default. Running an admin console even if it is OSGi's admin console on the normal application port (8080) is not a good idea, IMHO.
        Hide
        Sanjeeb Sahoo added a comment -

        Pl. open a new enhancement request if you are not able to configure it using cfg file as suggested earlier.

        I don't understand your point of using modules/autostart for cfg file. You are not supposed to modify anything inside installation directory. domain_dir is a user controlled area and hence you should use that to do any domain level configuration such as this.

        Show
        Sanjeeb Sahoo added a comment - Pl. open a new enhancement request if you are not able to configure it using cfg file as suggested earlier. I don't understand your point of using modules/autostart for cfg file. You are not supposed to modify anything inside installation directory. domain_dir is a user controlled area and hence you should use that to do any domain level configuration such as this.
        Hide
        aaronjwhiteside added a comment -

        OK, do you want me to open another bug to have the OSGi console run on the admin listener (4848) instead of the http-listener (8080)? Or can you reuse this issue?

        Show
        aaronjwhiteside added a comment - OK, do you want me to open another bug to have the OSGi console run on the admin listener (4848) instead of the http-listener (8080)? Or can you reuse this issue?

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            aaronjwhiteside
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: