[GLASSFISH-19419] properties are not persisted properly into the domain.xml file Created: 09/Dec/12  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b66
Fix Version/s: 4.0_b71

Type: Bug Priority: Critical
Reporter: pbelbin Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

jdk 7u9 x64 windows

Attachments: PNG File debug.png    


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:


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.

Comment by Anissa Lam [ 09/Dec/12 ]

Sounds like a gui issue. Will look into that

Comment by Anissa Lam [ 13/Dec/12 ]

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.

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.

Comment by Tim Quinn [ 04/Jan/13 ]

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.

Comment by Tim Quinn [ 09/Jan/13 ]

Fixes checked in.

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

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


Modified Paths:

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

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


Modified Paths:

Generated at Thu Oct 27 05:59:44 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.