You forgot one very important item on your checklist of things to do
when moving things in domain.xml: tell the tech writers. The alias is
docs_at_glassfish.dev.java.net. This is especially important in the
absence of a DTD.
June Parks
On 08/31/09 14:05, Justin Lee wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>