Sorry for the confusion.  This work may not be approved for the next release and we need to more carefully look at upgrade scenarios and test impact.  So, I've disabled the use of the custom pref impl by default.  Back to native prefs impl until further notice.

Nothing else has changed, the support is still there.  If you want to use it edit your rhq-agent.sh|bat and switch to the commented cmd line that includes the override.

-Jay

On 3/25/2013 2:50 PM, Jay Shaughnessy wrote:

I just pushed changes for https://bugzilla.redhat.com/show_bug.cgi?id=824010.   With this change the agent no longer uses the native implementation of Java Preferences. Instead, it uses our custom implementation (FilePreferences.java).   Now the agent configuration will be stored in a configurable file, as opposed to the default file location on Linux and the registry on windows.

By default, and there shouldn't be a lot of need to change from the default, the agent config will be placed in RHQ_AGENT_HOME/conf/agent-prefs.properties.

For new agents there shouldn't be any discernible difference in behavior, other than the new file being generated.  For existing agents the preferences will be migrated from the native storage to our file storage during the agent auto update procedure.

BUT, for your dev environments, where you likely don't go through an autoupdate, you have a few options. Start by:

1) bring down your agent.
2) rebuild the agent: mvn -Pagent

Option 1 (easiest, new agent):

3) delete your registered agent, either via the new Delete button under Administration->Topology->Agents or by just doing a dbsetup.
4) start your new agent and enter the setup info as usual
Option 2 (recommended, autoupdate):
3) rebuild the appserver/autoupdate module
4) copy the autoupdate jar to your agent home dir
5) > java -jar rhq-enterprise-agentupdate-4.7.0-SNAPSHOT.jar -u
6) your updated agent should now be running and using the migrated prefs

Note, option 1 will leave your old prefs in the native prefs store.  Option 2 will clean them up as part of the migration. If you have time try option 2, it will test the code better and do the cleanup.

Jay



_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel