Issue Details (XML | Word | Printable)

Key: GLASSFISH-19361
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Tom Mueller
Reporter: Anissa Lam
Votes: 0
Watchers: 0
Operations

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

create-system-properties cannot handle the case where the property name already exists.

Created: 21/Nov/12 08:01 AM   Updated: 30/Nov/12 06:27 PM   Resolved: 22/Nov/12 03:44 AM
Component/s: configuration
Affects Version/s: 3.1.2, 3.1.2.2
Fix Version/s: 4.0_b64_EE7MS2

Time Tracking:
Not Specified

File Attachments: 1. File EnumProperties.war (1 kB) 21/Nov/12 08:03 AM - Anissa Lam


Tags:
Participants: Anissa Lam and Tom Mueller


 Description  « Hide

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.



Tom Mueller added a comment - 30/Nov/12 06:27 PM

Backported to 3.1.2-SUSTAINING branch (revision 8351).


Tom Mueller added a comment - 22/Nov/12 03:44 AM

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.


Anissa Lam added a comment - 22/Nov/12 12:48 AM

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.


Tom Mueller added a comment - 21/Nov/12 07:29 PM

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.


Tom Mueller added a comment - 21/Nov/12 03:29 PM

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.