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.
>