Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1.1_b10
    • Component/s: rest-interface
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      build: ogs-3.1-b28-11_05_2010.zip

      I deployed scrumtoys.war to DAS and got the following message displayed in GUI:

      Deployment has succeeded with following warning, please look at the log file
      for details
      Application deployed with name scrumtoys.

      The above message should either quote the warning from server.log file or, if
      that's not possible, it should read:

      Deployment succeeded with a warning, please look at the log file for details
      Application deployed with name scrumtoys.

      The warning in server.log pertains to the fact that tables could not be created
      since database was not started.

      1. server.log
        32 kB
        lidiam

        Issue Links

          Activity

          Hide
          Tim Quinn added a comment -

          Transferring this to deployment.

          The proposed fix for 3.1.1 would be to report a "warning" status for the whole deployment if at least one subcommand reports a "warning."

          Why fix this issue in 3.1.1?
          The CLI displays warning substatus info, but the GUI does not. Anissa reports that GUI changes to handle this would be risky at this point. The proposed change would allow the GUI to detect the incomplete deployment and act accordingly without disrupting how the CLI reports it.

          Which is the targeted build of 3.1.1 for this fix?
          b10

          Do regression tests exist for this issue?
          not sure - maybe in the GUI?

          Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
          any test which deploys an app

          Show
          Tim Quinn added a comment - Transferring this to deployment. The proposed fix for 3.1.1 would be to report a "warning" status for the whole deployment if at least one subcommand reports a "warning." Why fix this issue in 3.1.1? The CLI displays warning substatus info, but the GUI does not. Anissa reports that GUI changes to handle this would be risky at this point. The proposed change would allow the GUI to detect the incomplete deployment and act accordingly without disrupting how the CLI reports it. Which is the targeted build of 3.1.1 for this fix? b10 Do regression tests exist for this issue? not sure - maybe in the GUI? Which tests should QA (re)run to verify the fix did not destabilize GlassFish? any test which deploys an app
          Hide
          Bhakti Mehta added a comment -

          Fixed this issue from the CLI side. Thanks to Tim for all his help
          svn rev 47757
          branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java
          branches/3.1.1/common/glassfish-api/src/main/java/org/glassfish/api/ActionReport.java

          According to Mitesh's email We seem to mishandle status in ActionReportResult. Various callers of ResourceUtil.getActionResportResult() attempts to translate ActionReport.ExitCode to https status codes and the method ResourceUtil.getActionResportResult() again attempts to translate the http status code into one of the ActionReport.ExitCode enums!!. I am proposing that we stop doing this double translation and modify all the callers of ResourceUtil.getActionResportResult() to pass in ActionReport.ExitCode.

          Reassigning to him to fix this from the REST side

          Show
          Bhakti Mehta added a comment - Fixed this issue from the CLI side. Thanks to Tim for all his help svn rev 47757 branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java branches/3.1.1/common/glassfish-api/src/main/java/org/glassfish/api/ActionReport.java According to Mitesh's email We seem to mishandle status in ActionReportResult. Various callers of ResourceUtil.getActionResportResult() attempts to translate ActionReport.ExitCode to https status codes and the method ResourceUtil.getActionResportResult() again attempts to translate the http status code into one of the ActionReport.ExitCode enums!!. I am proposing that we stop doing this double translation and modify all the callers of ResourceUtil.getActionResportResult() to pass in ActionReport.ExitCode. Reassigning to him to fix this from the REST side
          Hide
          Anissa Lam added a comment -

          The bug is now in the rest-interface land.

          Show
          Anissa Lam added a comment - The bug is now in the rest-interface land.
          Hide
          Mitesh Meswani added a comment -

          Fixed with 47804

          Show
          Mitesh Meswani added a comment - Fixed with 47804
          Hide
          lidiam added a comment -

          Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip, detailed error message is displayed.

          Show
          lidiam added a comment - Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip, detailed error message is displayed.

            People

            • Assignee:
              Mitesh Meswani
              Reporter:
              lidiam
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: