glassfish
  1. glassfish
  2. GLASSFISH-15961

some l10n man pages are not loaded when the server is running

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_b42
    • Component/s: command_line_interface
    • Labels:
      None

      Description

      Some of the l10n man pages are not loaded when the server is running like asadmin help list-clusters.
      The asadmin client does the lookup correctly. it seems that the logic is missing on the server side.

        Activity

        Hide
        Chris Kasso added a comment -

        Georges - Can you give us an idea of how many commands are afflicted with this issue?

        Show
        Chris Kasso added a comment - Georges - Can you give us an idea of how many commands are afflicted with this issue?
        Hide
        gmurr added a comment -

        I don't know how many. The man pages are returned either by the client or the server, I don't know how the logic is implemented to make the distinction. However all l10n man pages are displayed correctly if the server is not running.

        Show
        gmurr added a comment - I don't know how many. The man pages are returned either by the client or the server, I don't know how the logic is implemented to make the distinction. However all l10n man pages are displayed correctly if the server is not running.
        Hide
        Chris Kasso added a comment -

        How does the failure manifest itself to the user? Do they see the man page in english or do they get an error?

        Show
        Chris Kasso added a comment - How does the failure manifest itself to the user? Do they see the man page in english or do they get an error?
        Hide
        gmurr added a comment -

        They see the EN man page

        Show
        gmurr added a comment - They see the EN man page
        Hide
        Bill Shannon added a comment -

        The root problem here is that the code to find the localized man pages
        doesn't even exist in the server! Ouch! Prior testing of localized man
        pages only tested when the server is down, in which case asadmin does all
        the work of finding the man page. The fix it to adapt the man-page-finding
        code from asadmin so that it can work in the server.

        How bad is its impact? (Severity)
        Pretty bad. Localized man pages aren't found at all.
        Previous 3.x releases haven't provided localized man pages.

        How often does it happen? (Frequency)
        Even time in non-English locales.

        How much effort is required to fix it? (Cost)
        It took me several hours to fix it.

        What is the risk of fixing it? (Risk)
        Moderate. I've isolated the fix to the server code that finds man pages,
        even though the asadmin code that does the same should be refactored to
        use common code; that will wait for 3.2. The risk is that the fix might
        break finding the default man pages in some case that testing won't detect.
        Fortunately, the fix is isolated to the man-page-finding code.

        Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
        The workaround is to only ask for man pages when the server is down,
        or to supply the wrong server coordinates to asadmin so it thinks the
        server is down.

        If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
        Absolutely.

        How long has the bug existed in the product?
        Since 3.0.

        Do regression tests exist for this issue?
        Not that I'm aware of.

        Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
        Any tests that involve finding man pages. I think the risk of
        destabilization outside the man page area is extremely small.

        When will a tested fix be ready for integration?
        Later today.

        Show
        Bill Shannon added a comment - The root problem here is that the code to find the localized man pages doesn't even exist in the server! Ouch! Prior testing of localized man pages only tested when the server is down, in which case asadmin does all the work of finding the man page. The fix it to adapt the man-page-finding code from asadmin so that it can work in the server. How bad is its impact? (Severity) Pretty bad. Localized man pages aren't found at all. Previous 3.x releases haven't provided localized man pages. How often does it happen? (Frequency) Even time in non-English locales. How much effort is required to fix it? (Cost) It took me several hours to fix it. What is the risk of fixing it? (Risk) Moderate. I've isolated the fix to the server code that finds man pages, even though the asadmin code that does the same should be refactored to use common code; that will wait for 3.2. The risk is that the fix might break finding the default man pages in some case that testing won't detect. Fortunately, the fix is isolated to the man-page-finding code. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user? The workaround is to only ask for man pages when the server is down, or to supply the wrong server coordinates to asadmin so it thinks the server is down. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? Absolutely. How long has the bug existed in the product? Since 3.0. Do regression tests exist for this issue? Not that I'm aware of. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Any tests that involve finding man pages. I think the risk of destabilization outside the man page area is extremely small. When will a tested fix be ready for integration? Later today.
        Hide
        Chris Kasso added a comment -

        Approved for RC3 pending:

        1) Code review
        2) The obligatory QL testing
        2) A better understanding of how to validate the fix. That may just mean poking at a bunch of man pages.

        Show
        Chris Kasso added a comment - Approved for RC3 pending: 1) Code review 2) The obligatory QL testing 2) A better understanding of how to validate the fix. That may just mean poking at a bunch of man pages.
        Hide
        Bill Shannon added a comment -

        Fixed.

        3.1 revision 45078
        trunk revision 45089

        Show
        Bill Shannon added a comment - Fixed. 3.1 revision 45078 trunk revision 45089
        Hide
        gmurr added a comment -

        Fix verified in promoted 3.1 b42

        Show
        gmurr added a comment - Fix verified in promoted 3.1 b42

          People

          • Assignee:
            Bill Shannon
            Reporter:
            gmurr
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: