Agreed, since it takes some advanced knowledge to understand how to do
it right.
On Sep 29, 2009, at 4:44 PM, Justin Lee wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> 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