Very true! My apologies.
June.Parks_at_Sun.COM wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>