Issue Details (XML | Word | Printable)

Key: GLASSFISH-19419
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Tim Quinn
Reporter: pbelbin
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

properties are not persisted properly into the domain.xml file

Created: 09/Dec/12 07:03 PM   Updated: 09/Jan/13 05:00 PM   Resolved: 09/Jan/13 05:00 PM
Component/s: admin
Affects Version/s: 4.0_b66
Fix Version/s: 4.0_b71

Time Tracking:
Not Specified

File Attachments: None
Image Attachments:

1. debug.png
(135 kB)
Environment:

jdk 7u9 x64 windows


Tags:
Participants: Anissa Lam, pbelbin and Tim Quinn


 Description  « Hide

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.



Tim Quinn added a comment - 09/Jan/13 05:00 PM

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


Tim Quinn added a comment - 04/Jan/13 05:59 PM

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.


Anissa Lam added a comment - 13/Dec/12 06:34 AM

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.


Anissa Lam added a comment - 09/Dec/12 09:01 PM

Sounds like a gui issue. Will look into that