Bug 726130

+++ This bug was initially created as a clone of Bug #694660 +++

The problem is detailed in 

https://issues.jboss.org/browse/EMBJOPR-350
https://issues.jboss.org/browse/JBPAPP-5285

There could potentially be multiple problem here:
1) Handling of unset option in Embedded Console UI
2) Handling of unset option in JON UI
3) Handling of unset option in jboss-as5 plugin

First of all lets make sure that 2) and 3) are addressed in rhq master from there we can see if any changes are required in Embedded Jopr.

--- Additional comment from ian.springer on 2011-04-14 12:35:49 EDT ---

This is an issue with the as5 plugin and the profile service. Properties that were unset would eventually revert back to their previous values. [master 10dfbb1] improves things - now properties that are unset will revert to the default value defined by the profile service MO, if any. If no default is defined, its value will remain unset (null). Ideally, all properties that were unset would remain unset (null), but it currently doesn't look like this is possible due to limitations on the JBAS side.

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=10dfbb14b4e20f42e49acce301d4162b16dee9a2

--- Additional comment from mfoley on 2011-05-02 13:19:42 EDT ---

verified setting/unsetting properties in jboss plugin.  RHQ 4.0 release candidate #2.

--- Additional comment from loleary on 2011-05-03 15:43:21 EDT ---

We need to get this addressed and tested in Embedded Jopr now. I originally attempted to use the updated AS5 plug-in from master with Embedded Jopr but the problem still existed. Which means that an additional fix is needed for Embedded JOPR or the AS5 plug-in, with the fix applied, didn't work in my test case.

--- Additional comment from ian.springer on 2011-05-09 10:16:02 EDT ---

Larry,

What is your test case and exactly what behavior do you see? 

As described in my comment, my "fix" improves the situation a bit but doesn't completely fix it. Properties that you unset will still end up reverting back to some internal default value in some cases. This is due to how things work on the AS side, and I don't see any way to work around it.

--- Additional comment from loleary on 2011-05-09 12:40:01 EDT ---

See the steps listed in the description of the upstream bug - https://issues.jboss.org/browse/JBPAPP-5285. 

Basically, the behavior is the exact same as it was pre-patch. When I test in RHQ, your fix works as expected. I understand you say "partial fix" but I think really this is the expected behavior. The goal from a user's perspective is to "unset" it (reverting it to its default). In RHQ, I see this. When I set the SQL to something and later change my mind, I see it gets unset in the AS instance or returns to its default.

But, using your patch in admin-console, there is no change. If I set the SQL, I can see the SQL set on the datasource in AS. If I unset the SQL (expecting it to revert to its default) I still see the SQL that was originally set after applying the "unset".

So, this either means that we need to do something more for admin-console or I was very naive in thinking that I could apply your patch to admin-console for testing.

--- Additional comment from ian.springer on 2011-05-09 17:22:49 EDT ---

No, I don't think you were being naive. The code for updating configs in the as5 plugin is the same code, whether the plugin is inside an RHQ Agent or inside the managed AS instance. The only difference is that when inside an Agent, the profile service is looked up from local JNDI, but when inside the managed AS instance, the profile service is looked up from remote JNDI over a JNP connection. It's possible there's a bug in the profile service where, when it was looked up locally, setting managed properties to null does not work correctly. In any case, I can't think what else we can do differently on the RHQ plugin side.

--- Additional comment from ian.springer on 2011-05-13 11:08:23 EDT ---

Argh, actually this is still broken for certain properties (I think ones that do not have default in the corresponding profile service managed properties). For example, the Check Valid Connection SQL and Query Timeout properties on Datasources. Such properties revert back to their previous values after being unset...

--- Additional comment from ian.springer on 2011-05-13 16:50:18 EDT ---

I have tried all of the following methods of setting a ManagedProperty to null in the jboss-as-5 plugin, to no avail:

1) managedProperty.getValue().setValue(null)
2) managedProperty.setValue(null)
3) managedPropertyMap.remove(managedProperty.getName())
4) managedProperty.setRemoved(true)

In all cases, for the problematic properties (e.g. Query Timeout), after setting the property to null and updating the corresponding ManagedComponent, the JBAS side revert the property back to the value it had just prior to setting it to null.

I don't know what else to try. I think this needs to be fixed on the AS/EAP side.

--- Additional comment from loleary on 2011-05-13 22:03:52 EDT ---

Can you provide me the class names that you are invoking and/or a sample showing how we are invoking this? I originally suspected it was on the EAP side when the ticket was opened but what made me think it wasn't was the configuration  parser. It seemed that the property got set to null (unset) but after parser, the property was somehow removed because the parser seems to ask EAP for the base configuration which does not include the property because in EAP these properties are undefined to begin with. However, if you are invoking the managed component in EAP directly and setting one of its properties to null and it is having to affect, then it has to be an EAP problem.

--- Additional comment from ian.springer on 2011-05-16 13:10:28 EDT ---

This ended up being several bugs in the as5 plugin after all. [master 4e72ffc] should put this one to bed.

--- Additional comment from loleary on 2011-05-16 15:44:40 EDT ---

I tested the original use case of setting Check Valid Connection SQL and then attempting to unset it using admin-console along with the proposed fixes from this BZ and the JIRA and everything tested okay. The unset worked and it is truly unset from a ProfileService perspective. 

Now we will just need to await the results from QA.

--- Additional comment from mfoley on 2011-05-24 15:22:18 EDT ---

verified.  did view, edit, save operations on AS5 datasource.