[GLASSFISH-19419] properties are not persisted properly into the domain.xml file Created: 09/Dec/12 Updated: 09/Jan/13 Resolved: 09/Jan/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
jdk 7u9 x64 windows
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.
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.
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.
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
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.
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
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