glassfish
  1. glassfish
  2. GLASSFISH-19419

properties are not persisted properly into the domain.xml file

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b66
    • Fix Version/s: 4.0_b71
    • Component/s: admin
    • Labels:
      None
    • Environment:

      jdk 7u9 x64 windows

      Description

      using the latest postgresql jdbc jar (http://jdbc.postgresql.org/download/postgresql-9.2-1002.jdbc4.jar) I tried to configure a jdbc connection pool.

      I used:
      resource type of javax.sql.DataSource
      database driver vendor: postgresql
      introspect: not checked.

      On the next page (after clicking 'next') I was presented with the usual suspects in terms of additional properties, and I populated these:

      user
      databaseName
      password
      serverName
      portNumber

      and hit 'finish'

      the admin gui reported that the ping had failed.

      I then checked the additional properties page, and found that only the 'user' value appeared.

      I found that this was the only value for this connection pool that was present in the domain.xml file.

        Activity

        Hide
        Anissa Lam added a comment -

        Sounds like a gui issue. Will look into that

        Show
        Anissa Lam added a comment - Sounds like a gui issue. Will look into that
        Hide
        Anissa Lam added a comment -

        I looked into this, and see that this is not specific to the JDBC properties. All the properties screen in the console cannot add properties correctly. So, I am bumping this up to P2.
        In any property table, only one new property will be added even though the user adds more than 1 property.
        I trace it down to the REST code and then the admin command. The 'set' command is called with the parameters map consisting of all the new properties.

        In CommandRunnerImpl.goCommand:1420
        report = doCommand(model, command, context, progressHelper);

        The 'values' of command seems correct, consisting of all the new properties that should be set. (see attached debug image from debugger).

        However, in the execute() method of SetCommand, it failed in the 2nd SetOperation, and thus didn't continue with setting the rest.
        This corresponds to setting the description which is empty.
        "resources.jdbc-connection-pool.DerbyPool.property.FIRST.description=""

        Looks like setting the description field is the curlpit. Not sure if REST or admin code needs to be fixed.

        I also narrowed it down to that promoted build 59 is still working fine, but b60 is showing this issue.

        To reproduce this using console, follow this step
        1. In the navigation tree, go to Resources -> JDBC -> JDBC Connection Pool -> Derby Pool
        2. Go to the Additional Tab of Derby Pool
        3. Add the pair of property: FIRST : firstValue and SECOND : secondValue
        4. click Save.

        You will then see that only FIRST is saved.

        Show
        Anissa Lam added a comment - I looked into this, and see that this is not specific to the JDBC properties. All the properties screen in the console cannot add properties correctly. So, I am bumping this up to P2. In any property table, only one new property will be added even though the user adds more than 1 property. I trace it down to the REST code and then the admin command. The 'set' command is called with the parameters map consisting of all the new properties. In CommandRunnerImpl.goCommand:1420 report = doCommand(model, command, context, progressHelper); The 'values' of command seems correct, consisting of all the new properties that should be set. (see attached debug image from debugger). However, in the execute() method of SetCommand, it failed in the 2nd SetOperation, and thus didn't continue with setting the rest. This corresponds to setting the description which is empty. "resources.jdbc-connection-pool.DerbyPool.property.FIRST.description="" Looks like setting the description field is the curlpit. Not sure if REST or admin code needs to be fixed. I also narrowed it down to that promoted build 59 is still working fine, but b60 is showing this issue. To reproduce this using console, follow this step 1. In the navigation tree, go to Resources -> JDBC -> JDBC Connection Pool -> Derby Pool 2. Go to the Additional Tab of Derby Pool 3. Add the pair of property: FIRST : firstValue and SECOND : secondValue 4. click Save. You will then see that only FIRST is saved.
        Hide
        Tim Quinn added a comment -

        Tom has correctly noted that this particular case has not worked since the changes in SetCommand to handle authorization.

        He has also pointed out this easy CLI example which triggers the problem:

        asadmin set resources.jdbc-connection-pool.DerbyPool.property.FIRST=firstValue resources.jdbc-connection-pool.DerbyPool.property.FIRST.description=bar

        When first run, the command fail. If that command is repeated, it succeeds.

        The underlying problem is that the current SetCommand implementation tries to find out some information about each operation specified on the command line as part of preparing the security access controls. Getting that information depends on the config hierarchy above the target being in place, and that is not true for the second part of the example "set" command above. That causes the current implementation's attempt to execute the second part to fail when the command is first run. On the second run, though, the expected parent is in place (established by the first part of the command) and the command succeeds.

        Show
        Tim Quinn added a comment - Tom has correctly noted that this particular case has not worked since the changes in SetCommand to handle authorization. He has also pointed out this easy CLI example which triggers the problem: asadmin set resources.jdbc-connection-pool.DerbyPool.property.FIRST=firstValue resources.jdbc-connection-pool.DerbyPool.property.FIRST.description=bar When first run, the command fail. If that command is repeated, it succeeds. The underlying problem is that the current SetCommand implementation tries to find out some information about each operation specified on the command line as part of preparing the security access controls. Getting that information depends on the config hierarchy above the target being in place, and that is not true for the second part of the example "set" command above. That causes the current implementation's attempt to execute the second part to fail when the command is first run. On the second run, though, the expected parent is in place (established by the first part of the command) and the command succeeds.
        Hide
        Tim Quinn added a comment -

        Fixes checked in.

        Project: glassfish
        Repository: svn
        Revision: 58187
        Author: tjquinn
        Date: 2013-01-07 18:49:41 UTC
        Link:

        Log Message:
        ------------
        Further fix for 19419

        The new test in "prepare" for identifying a dotted name reference to a property assumed that the "property" string identifying that the target is a property would not be the first part of the string, but that's actually permitted. The GlassFish admin devtests revealed this.

        Tests: the offending admin devtest

        Revisions:
        ----------
        58187

        Modified Paths:
        ---------------
        trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java

        ===========================================================================================
        Project: glassfish
        Repository: svn
        Revision: 58181
        Author: tjquinn
        Date: 2013-01-07 15:42:21 UTC
        Link:

        Log Message:
        ------------
        Fix for 19419

        Earlier changes to allow us to authorize each name/value pair separately did not correctly handle cases in which a later name/value pair's validity depended on the successful execution of an earlier name/value pair assignment.

        This change returns the set command implementation closer to its original implementation. We still need to do some preparation work as part of preAuthorization, before each name/value pair assignment is actually performed, but the new implementation works for the case described above.

        Tests: QL, admin devtests

        Revisions:
        ----------
        58181

        Modified Paths:
        ---------------
        trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java

        Show
        Tim Quinn added a comment - Fixes checked in. Project: glassfish Repository: svn Revision: 58187 Author: tjquinn Date: 2013-01-07 18:49:41 UTC Link: Log Message: ------------ Further fix for 19419 The new test in "prepare" for identifying a dotted name reference to a property assumed that the "property" string identifying that the target is a property would not be the first part of the string, but that's actually permitted. The GlassFish admin devtests revealed this. Tests: the offending admin devtest Revisions: ---------- 58187 Modified Paths: --------------- trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java =========================================================================================== Project: glassfish Repository: svn Revision: 58181 Author: tjquinn Date: 2013-01-07 15:42:21 UTC Link: Log Message: ------------ Fix for 19419 Earlier changes to allow us to authorize each name/value pair separately did not correctly handle cases in which a later name/value pair's validity depended on the successful execution of an earlier name/value pair assignment. This change returns the set command implementation closer to its original implementation. We still need to do some preparation work as part of preAuthorization, before each name/value pair assignment is actually performed, but the new implementation works for the case described above. Tests: QL, admin devtests Revisions: ---------- 58181 Modified Paths: --------------- trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java

          People

          • Assignee:
            Tim Quinn
            Reporter:
            pbelbin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: