This probably doesn't apply to most of you but some of you, like myself,
find yourself needing to rename or move a configuration element but hold
back because it'll break a script. I just checked in an
interface/Contract you can implement, however, that will fix that:
org.glassfish.api.admin.config.LegacyConfigurationUpgrade. We've had
the ConfigurationUpgrade interface for some time but that's only applied
at server start up and doesn't address any calls to "asadmin set" that
might try to set these old values. This new interface, in all it's
awkwardly named glory, defines processes that will be run at the end of
the set command to move/rename/delete any deprecated values without
causing the set command to fail. There are, however, a few provisos, a
few quid pro quos:
1. The old location has to remain in the interface for the
configuration bean. You should definitely mark them as deprecated
so people stop using them in code, but they have to remain. Why?
So that the set commands will succeed and so you can grab the
values from that old location and move it to the new location.
2. You should inform the user that you've moved the value (s)he just
set so scripts can be updated.
3. There is a base implementation you can use if you want:
org.glassfish.config.support.BaseLegacyConfigurationUpgrade. This
has support for taking a config bean, a property, and an attribute
name and moving the value to the new location. In my
grizzly-config work (and beyond) this has been a fairly common
request so this might help a number of you. This method takes of
notifying the user for you saving you even more work. There's 0
i18n support for this at the moment so that's an area we'll need
to enhance.
4. A simple example implementation can be found in
org.glassfish.config.support.HttpServicePropertiesUpgrade.
Barring any SCF barriers that prevent me from doing so, I'll
possibly be adding more implementations to support all the grizzly
config changes to the schema as we're still finding SQE scripts
and the like that fail due to some of those changes.
5. I would recommend that if you write many of these (and hopefully
you don't...) that you try to write one interface per config bean
as these will be executed after each set looking for old values to
update. If we get too many, it could have deleterious effects on
the command's performance.
And that's about it. This should give us a bit of breathing room should
we need to shift things around in domain.xml. If you'd like a little
more detail (there's not much) the issue related to this change is
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9219.