glassfish
  1. glassfish
  2. GLASSFISH-20192

ADMINGUI : Load default does not change the deployment order value

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b83
    • Fix Version/s: 4.0_b86_RC2
    • Component/s: admin_gui
    • Labels:
      None
    • Environment:

      win 7 FF19

      Description

      Open created context services.
      "Edit context service screen" will display.
      change the value of deployment order from 100 to 105.
      click the Load defaults button now.
      Deployment order value should be change to 100 as per the default value given in the online help document.
      But it is not happening. it still shows as 105 only.

        Issue Links

          Activity

          Hide
          Jagadish added a comment -

          Anissa, Jason :

          deployment-order is an attribute that does not take effect during creation of resource. It takes effect only during subsequent startups of application server.
          Because of this, we have not made "deployment-order" to be a command parameter.
          Also, there are 10-12 different create-xxx-resource commands and we did not want to introduce this attribute since it does not take effect during creation time.

          Note :
          There is also "object-type" attribute for each type of resource, but not specified during resource creation time (ie., create-xxx-resource commands).

          So, the ideal solution would be for REST to have an API to return default values of config bean attributes too. Transferring to Jason based on Anissa's latest comment to decide whether it needs to be taken care of in 4.0 or later release.

          Show
          Jagadish added a comment - Anissa, Jason : deployment-order is an attribute that does not take effect during creation of resource. It takes effect only during subsequent startups of application server. Because of this, we have not made "deployment-order" to be a command parameter. Also, there are 10-12 different create-xxx-resource commands and we did not want to introduce this attribute since it does not take effect during creation time. Note : There is also "object-type" attribute for each type of resource, but not specified during resource creation time (ie., create-xxx-resource commands). So, the ideal solution would be for REST to have an API to return default values of config bean attributes too. Transferring to Jason based on Anissa's latest comment to decide whether it needs to be taken care of in 4.0 or later release.
          Hide
          Jason Lee added a comment -

          At the risk of repeating myself, the REST interface does have an API for returning the default value; the Console just isn't using the correct URL, which I've shared above. It would be better if the REST interface could give all the attributes for a ConfigBean from the URL the Console is using now, but, as I've noted, the system does not provide the metadata needed to get from the AdminCommand to the ConfigBean. It's also not so simple as mapping the command to the bean, as a single command can operate on 0 or more ConfigBeans, so returning the default values for all, say, 5 ConfigBeans a command touches, were it possible, would be confusing to the REST client developer.

          As it is, the URL the Console is using returns the creation defaults. The URL it should be using returns the defaults for updates. It's possible, I guess, for the REST interface to combine the two, but it's not as straightforward as it may seem for the reasons listed above. That change, though, would need to be a separate RFE filed for 4.next. That kind of change this far after HCF can not be made. The fix for the Console behavior, then, if any is to be delivered for this release, needs to come from the either console side or from the AdminCommand. I'll leave it to you two to decide where. Personally, I don't think adding the parameter to the AdminCommand even though it's only used at startup should be problematic.

          Show
          Jason Lee added a comment - At the risk of repeating myself, the REST interface does have an API for returning the default value; the Console just isn't using the correct URL, which I've shared above. It would be better if the REST interface could give all the attributes for a ConfigBean from the URL the Console is using now, but, as I've noted, the system does not provide the metadata needed to get from the AdminCommand to the ConfigBean. It's also not so simple as mapping the command to the bean, as a single command can operate on 0 or more ConfigBeans, so returning the default values for all, say, 5 ConfigBeans a command touches, were it possible, would be confusing to the REST client developer. As it is, the URL the Console is using returns the creation defaults. The URL it should be using returns the defaults for updates. It's possible, I guess, for the REST interface to combine the two, but it's not as straightforward as it may seem for the reasons listed above. That change, though, would need to be a separate RFE filed for 4.next. That kind of change this far after HCF can not be made. The fix for the Console behavior, then, if any is to be delivered for this release, needs to come from the either console side or from the AdminCommand. I'll leave it to you two to decide where. Personally, I don't think adding the parameter to the AdminCommand even though it's only used at startup should be problematic.
          Hide
          Anissa Lam added a comment - - edited

          I think the controversy here is how a default value should be available.
          I feel that REST should be able to provide the default value just by given the ConfigBean type, eg. jdbc-resource, thread-pool, virtual-server etc.
          But currently unless this attribute is one of the create command param, it cannot do that.
          REST requires the REST endpoint of a created instance in order to be able to provide the default values, and thus Jason is requesting the console code to be changed.

          Fix it properly by any of the mentioned alternative is too risky at this point. It is almost like a redesign in either the console or the REST code.
          I will file an RFE so we can work on this after 4.0

          For 4.0 release, it is a simple hack in the console to hard code "100" as the default value for dpeloyment-order. Almost no risk. So, I will take this approach and get approval for that.
          If the default value in later release is changed, then we need to change it again, but hopefully, by then, we have agreed on the way on how default value can be obtained and this hack is no longer necessary.

          Here is the svn diff.

          ~/Awork/GF/all/main/appserver/admingui/common/src/main/java/org/glassfish 14)  svn diff
          Index: admingui/common/handlers/RestApiHandlers.java
          ===================================================================
          --- admingui/common/handlers/RestApiHandlers.java	(revision 61361)
          +++ admingui/common/handlers/RestApiHandlers.java	(working copy)
          @@ -87,6 +87,11 @@
                               String defaultV = defaultValues.get(origKey);
                               if (defaultV != null) {
                                   orig.put(origKey, defaultV);
          +                    }else{
          +                        //this is a hack for 4.0. refer to GLASSFISH-20192
          +                        if (origKey.equals("deploymentOrder")){
          +                            orig.put(origKey, "100");
          +                        }
                               }
                           }
                           handlerCtx.setOutputValue("valueMap", orig);
          

          -------------------------------------------------------
          What is the impact on the customer of the bug?
          User is not able to find out the default value of 'deployment-order' for resources and applications after they have changed it.

          What is the cost/risk of fixing the bug?
          This is by hardcoding the value to be "100". very minimal risk. The proper fix will need to be after 4.0 as it is very involved.

          Is there an impact on documentation or message strings?

          No

          Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
          The same test that discovered this bug.

          Which is the targeted build of 4.0 for this fix?
          The fix is ready, not sure if it will make it into b85 or b86.

          If this an integration of a new version of a component from another project,
          what are the changes that are being brought in? This might be list of
          Jira issues from that project or a list of revision messages.

          n/a

          Show
          Anissa Lam added a comment - - edited I think the controversy here is how a default value should be available. I feel that REST should be able to provide the default value just by given the ConfigBean type, eg. jdbc-resource, thread-pool, virtual-server etc. But currently unless this attribute is one of the create command param, it cannot do that. REST requires the REST endpoint of a created instance in order to be able to provide the default values, and thus Jason is requesting the console code to be changed. Fix it properly by any of the mentioned alternative is too risky at this point. It is almost like a redesign in either the console or the REST code. I will file an RFE so we can work on this after 4.0 For 4.0 release, it is a simple hack in the console to hard code "100" as the default value for dpeloyment-order. Almost no risk. So, I will take this approach and get approval for that. If the default value in later release is changed, then we need to change it again, but hopefully, by then, we have agreed on the way on how default value can be obtained and this hack is no longer necessary. Here is the svn diff. ~/Awork/GF/all/main/appserver/admingui/common/src/main/java/org/glassfish 14) svn diff Index: admingui/common/handlers/RestApiHandlers.java =================================================================== --- admingui/common/handlers/RestApiHandlers.java (revision 61361) +++ admingui/common/handlers/RestApiHandlers.java (working copy) @@ -87,6 +87,11 @@ String defaultV = defaultValues.get(origKey); if (defaultV != null ) { orig.put(origKey, defaultV); + } else { + // this is a hack for 4.0. refer to GLASSFISH-20192 + if (origKey.equals( "deploymentOrder" )){ + orig.put(origKey, "100" ); + } } } handlerCtx.setOutputValue( "valueMap" , orig); ------------------------------------------------------- What is the impact on the customer of the bug? User is not able to find out the default value of 'deployment-order' for resources and applications after they have changed it. What is the cost/risk of fixing the bug? This is by hardcoding the value to be "100". very minimal risk. The proper fix will need to be after 4.0 as it is very involved. Is there an impact on documentation or message strings? No Which tests should QA (re)run to verify the fix did not destabilize GlassFish? The same test that discovered this bug. Which is the targeted build of 4.0 for this fix? The fix is ready, not sure if it will make it into b85 or b86. If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. n/a
          Hide
          Tom Mueller added a comment -

          Approved for 4.0. Please make sure an issue is filed to fix this properly and link to it from this issue.

          Show
          Tom Mueller added a comment - Approved for 4.0. Please make sure an issue is filed to fix this properly and link to it from this issue.
          Hide
          Anissa Lam added a comment -

          Change committed. Not sure if it makes into b85. Mark this fixed for RC2.
          GLASSFISH-20347 has been created to request REST to revisit the issue for 4.0.1.

          Date: 2013-04-18 17:12:58 UTC
          Log Message:
          ------------
          GLASSFISH-20192. Hardcode deployment-order default value to be "100".

          Revisions:
          ----------
          61542

          Modified Paths:
          ---------------
          trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/RestApiHandlers.java

          Show
          Anissa Lam added a comment - Change committed. Not sure if it makes into b85. Mark this fixed for RC2. GLASSFISH-20347 has been created to request REST to revisit the issue for 4.0.1. Date: 2013-04-18 17:12:58 UTC Log Message: ------------ GLASSFISH-20192 . Hardcode deployment-order default value to be "100". Revisions: ---------- 61542 Modified Paths: --------------- trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/RestApiHandlers.java

            People

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

              Dates

              • Created:
                Updated:
                Resolved: