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.