[GLASSFISH-19361] create-system-properties cannot handle the case where the property name already exists. Created: 21/Nov/12  Updated: 30/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.2,
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File EnumProperties.war    


I found this issue when trying to look at another issue where using REST to modify system property of a config failed.
When a user calls create-system-properties, but a property with that name already exists, it reports successful. Not sure if thats by design. However, any user application deployed to the server referencing that config will see that the property is gone, ie calling System.getProperties() will not return that property at all.

Here is the steps to reproduce. I am using DAS, but the same behavior is observed for any instance.
The war file EnumProperties is attached.

%asadmin start-domain
%asadmin deploy EnumProperties
%asadmin create-system-properties --target server-config AAA=aaa:BBB=bbb
launch the app by going to http://localhost:8080/EnumProperties, you can see the 2 properties.
now do
%asadmin create-system-properties --target server-config AAA=new-value
The command returns saying executed successfully.
domain.xml is updated with the new value, but run EnumProperties again, and you can see that only BBB is showing up.

If create-system-properties is working as expected, ie, it means modifying a property value if the property already exists, then System.getProperties() should return this property.

If create-system-properties is only for creating new property, then it should return error and not update domain.xml with this new value.

Comment by Tom Mueller [ 21/Nov/12 ]

The create-system-properties manual page says, "If any system properties were previously defined, they are updated with the new values."

So the bug here is that System.getProperties is not returning the value after the update.

Comment by Tom Mueller [ 21/Nov/12 ]

The root cause of this problem is that config bean change events are being delivered out of order to ConfigListener objects. When a system property is to be updated by create-system-properties, the command first removes the old property and then adds a new one. There is a comment in the code saying that SystemProperty.setValue doesn't work, so this is the reason for the delete and then add. However, the CombinedJavaConfigSystemPropertyListener class (the ConfigListener) receives the change events in the opposite order, i.e., the add is first followed by the delete. Thus, the result on the Java system properties is that the value is deleted.

Comment by Anissa Lam [ 22/Nov/12 ]

The REST code has been fixed to delete only those property that user has removed instead of deleting all existing properties, before calling create-system-properties.
It also goes through commands to do the delete so that replication works correctly.

Comment by Tom Mueller [ 22/Nov/12 ]

Fixed in revision 57081.

This fixes the create-system-properties command so that it only updates an existing property rather than deleting it and then adding it. This produces the correct behavior for the Java system properties.

Comment by Tom Mueller [ 30/Nov/12 ]

Backported to 3.1.2-SUSTAINING branch (revision 8351).

Generated at Sat Feb 06 20:43:10 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.