I was just wondering about that. So that might fix some of the
technical hurdles it doesn't really address usability issues. It's
looking like we'll need to write a change listener to handle some of this.
Lloyd Chambers wrote:
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>