Once Bill fixes the 'set' command to accept multiple arguments, the
implementation should be able to do both in one transaction.
Bill?
On Sep 29, 2009, at 11:24 AM, Justin Lee wrote:
> The bug I was forgetting is https://glassfish.dev.java.net/issues/show_bug.cgi?id=7240
> which deals with the synchronization of name changes. Changing a
> name is a two step process using the set command and you can't do
> both steps in one transaction so as soon as the first change is
> made, GlassFish will try to restart the affected containers and will
> fail because the lookups are now broken.
>
> Justin Lee wrote:
>> There are currently a handful of issues open that I think might be
>> related:
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8953
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8289
>>
>> I feel like I'm missing one or two, but those are the two big ones,
>> I think. The initial problem is that during creates of network-
>> listeners, we're missing a case or two and the network-listeners
>> attributes gets out of sync. We could fix those problems in the
>> CLI and GUI to solve that problem, but it doesn't really affect
>> when changes are made by "asadmin set." These changes are much
>> harder (if at all possible) to trap and update other areas of the
>> document so that things remain in sync. (Think: changing the
>> default virtual server for a listener/http pair such that it no
>> longer lives on the original virtual server).
>>
>> I think the better approach is to change
>> VirtualServer.getNetworkListeners() to be a @DuckType method and
>> make that value a calculated look up. This lets us change the
>> document without having to also do the bookkeeping of making sure
>> the virtual server element(s) remain in sync. These values as they
>> exist now are largely redundant and are just housekeeping values
>> anyway. Making them a lookup removes the burden of having to
>> remember to keep them in sync.
>>
>> Now this change is essentially a schema change so we might have to
>> take this to the CCC to get clearance. Depending on how it's
>> implemented, it might be a Java API change as well. We could just
>> collect the names of the listeners into a comma delimited string
>> like the API has now. Or we could enhance the API to return actual
>> NetworkListener reference so that users of the method don't have to
>> do the extra work of fetching each NetworkListener by name each
>> time. (Which I'm willing to bet is the most common case).
>>
>> What do you think? Am I missing anything? Is this a change we can/
>> should make? I personally think it's the right change to make if
>> we can get it past any governance concerns.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team