glassfish
  1. glassfish
  2. GLASSFISH-15852

when duplicate network listener is added, Error is displayed for a protocol.

    Details

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

      OS; Windows 2008
      browser firefox. 3.6

      Description

      GF build used : promoted b40.

      When we try to add a duplicate network listener, the error displayed is for the protocol. as below:
      An error has occurred

      {0}

      protocol already exists. Cannot add duplicate protocol.

      The Error should be displayed for the network listener.

      Even when we leave the "Name" field in the "New Network Listener" screen empty, then the Pop UP window asks to "Enter Name for the Protocol". It should be for the network listener.

        Activity

        Hide
        Anissa Lam added a comment -

        negative testing. No function problem, we fix the error msg in 3.2

        This kind of testing shouldn't be wait till 12 hours before RC2. code freeze

        Show
        Anissa Lam added a comment - negative testing. No function problem, we fix the error msg in 3.2 This kind of testing shouldn't be wait till 12 hours before RC2. code freeze
        Hide
        Anissa Lam added a comment -

        I looked at this, this is a error msg from the backend.
        If you do CLI create-protocol, you will see the

        {0}

        %asadmin create-protocol --target test AAA-protocol
        remote failure: {0}

        protocol already exists. Cannot add duplicate protocol.
        Command create-protocol failed.

        I have filed GLASSFISH-15871 for this.

        When you create a network listener, you need to create a protocol first, and then the network listener. GUI lets you specify both in one screen. But still need to create the protocol first.

        Since the protocol already exist, backend gives the above error and so GUI shows that to user.
        It is correct that this protocol already exist, but because of the bug GLASSFISH-15871, it is confusing.
        If you change the protocol name, this protocol will be created.
        Then the next step is to create the network listener.
        Now, if the listener exists, you will get the error that the listener already exist.

        So, GUI is doing the correct thing. Change your protocol name to an non-existent one and you will see the error about duplicate network listener name.

        Closing as Will not fix since this is expected behavior.

        Show
        Anissa Lam added a comment - I looked at this, this is a error msg from the backend. If you do CLI create-protocol, you will see the {0} %asadmin create-protocol --target test AAA-protocol remote failure: {0} protocol already exists. Cannot add duplicate protocol. Command create-protocol failed. I have filed GLASSFISH-15871 for this. When you create a network listener, you need to create a protocol first, and then the network listener. GUI lets you specify both in one screen. But still need to create the protocol first. Since the protocol already exist, backend gives the above error and so GUI shows that to user. It is correct that this protocol already exist, but because of the bug GLASSFISH-15871 , it is confusing. If you change the protocol name, this protocol will be created. Then the next step is to create the network listener. Now, if the listener exists, you will get the error that the listener already exist. So, GUI is doing the correct thing. Change your protocol name to an non-existent one and you will see the error about duplicate network listener name. Closing as Will not fix since this is expected behavior.
        Hide
        Anissa Lam added a comment -

        GUI and backend is doing the correct thing. The protocol that needs to be created first for this listener is indeed duplicate. Once user change the name of the dup. protocol, he will get the error of dup. listener.

        I am about to close this as will not fix, since this is expected.
        However, for better user experience, I am going to add the check for dup. listener first, and inform user of that. But even if i add this check but try to use an existing protocol, they will still get the dup. protocol error msg. This will be expected.

        Show
        Anissa Lam added a comment - GUI and backend is doing the correct thing. The protocol that needs to be created first for this listener is indeed duplicate. Once user change the name of the dup. protocol, he will get the error of dup. listener. I am about to close this as will not fix, since this is expected. However, for better user experience, I am going to add the check for dup. listener first, and inform user of that. But even if i add this check but try to use an existing protocol, they will still get the dup. protocol error msg. This will be expected.
        Hide
        Anissa Lam added a comment -

        -How bad is its impact? (Severity)
        GUI is doing the correct thing. But with GLASSFISH-15871 this is pretty confusing to user.

        How often does it happen? (Frequency)
        Whenever user wants to create a network listener, but also specify to create a new protocol that has already exist.

        -How much effort is required to fix it? (Cost)
        2 hours. The change of code is pretty trivial.

        -What is the risk of fixing it? (Risk)
        very small. Just add the test if network listener and protocol exist and inform user in that order. Instead of depending on backend.

        -Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
        Doesn't need any work around, whatever GUI doing now is technically correct.

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

        How long has the bug existed in the product?
        Probably since the beginning.

        Do regression tests exist for this issue?
        There are some devtest for realm, will need to add more for this case.

        Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
        The usual test they run and the GUI dev test.

        When will a tested fix be ready for integration?
        Ready now, svn diff attached.

        Show
        Anissa Lam added a comment - -How bad is its impact? (Severity) GUI is doing the correct thing. But with GLASSFISH-15871 this is pretty confusing to user. How often does it happen? (Frequency) Whenever user wants to create a network listener, but also specify to create a new protocol that has already exist. -How much effort is required to fix it? (Cost) 2 hours. The change of code is pretty trivial. -What is the risk of fixing it? (Risk) very small. Just add the test if network listener and protocol exist and inform user in that order. Instead of depending on backend. -Does a work around for the issue exist? Can the workaround be reasonably employed by the end user? Doesn't need any work around, whatever GUI doing now is technically correct. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? No. How long has the bug existed in the product? Probably since the beginning. Do regression tests exist for this issue? There are some devtest for realm, will need to add more for this case. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? The usual test they run and the GUI dev test. When will a tested fix be ready for integration? Ready now, svn diff attached.
        Hide
        sirajg added a comment -

        Changes look fine.

        Show
        sirajg added a comment - Changes look fine.
        Hide
        Anissa Lam added a comment -

        Fix checked into both trunk and 3.1 branch.

        Trunk: rev# 44965
        Branch: rev# 44966

        Project: glassfish
        Repository: svn
        Revision: 44966
        Author: anilam
        Date: 2011-02-07 19:45:30 UTC
        Link:

        Log Message:
        ------------
        GLASSFISH-15852. Provide correct error msg to user when creating network listener. GUI checks if listener exists first before calling backend to create the protocol.
        Fix checked into the trunk as rev# 44965

        Reviewed by Siraj, Chris
        Approved by Chris.

        Revisions:
        ----------
        44966

        Modified Paths:
        ---------------
        branches/3.1/admingui/web/src/main/resources/grizzly/protocolNewButtons.inc
        branches/3.1/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties
        branches/3.1/admingui/web/src/main/resources/grizzly/networkListenerNew.jsf

        Show
        Anissa Lam added a comment - Fix checked into both trunk and 3.1 branch. Trunk: rev# 44965 Branch: rev# 44966 Project: glassfish Repository: svn Revision: 44966 Author: anilam Date: 2011-02-07 19:45:30 UTC Link: Log Message: ------------ GLASSFISH-15852 . Provide correct error msg to user when creating network listener. GUI checks if listener exists first before calling backend to create the protocol. Fix checked into the trunk as rev# 44965 Reviewed by Siraj, Chris Approved by Chris. Revisions: ---------- 44966 Modified Paths: --------------- branches/3.1/admingui/web/src/main/resources/grizzly/protocolNewButtons.inc branches/3.1/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties branches/3.1/admingui/web/src/main/resources/grizzly/networkListenerNew.jsf
        Hide
        shaline added a comment -

        Verified in GF nightly build dated b42-02-09-2011

        Show
        shaline added a comment - Verified in GF nightly build dated b42-02-09-2011

          People

          • Assignee:
            Anissa Lam
            Reporter:
            shaline
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: