I would like to bring up an issue that came up in connection with
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6424
("404 error from launch link after add new http listener and
virtual server")
At the core of this issue stands the following question:
If the "--virtualservers" option is omitted from the deploy command,
we interpret this to mean "Deploy to all virtual servers".
But what should "all virtual servers" mean: Should it only refer to all
currently active virtual servers, or should it also include virtual
servers that may be added down the road?
My preference would be the former interpretation (which is what's been
implemented in GlassFish v2 and v3 prelude), in which case Issue 6424
could be closed as invalid: I think it is unexpected (if not dangerous)
for an app to become accessible on one or more virtual servers that were
created after the app's deployment. (You could argue, though, that if you
wanted to play it safe, you'd always specify "--virtualservers" during
deployment.)
But there is a problem right now in that the absence of
"--virtualservers" during deployment also causes the "virtual-servers"
attribute to be dropped from the app's <application-ref> in
domain.xml, with the effect that if one or more virtual servers are
created after the app's deployment, the app will automatically be deployed
to them following a server restart.
In order to address this, I think the deployment/admin should always
populate the "virtual-servers" attribute of an app's <application-ref>
in domain.xml, even in the absence of "--virtualservers". In this
case, a snapshot of all currently active virtual servers should be
taken, and their ids stored in the "virtual-servers" attribute. Should
new virtual servers be added down the road, the app won't be deployed
to them, not even after a restart.
Please let me know your thoughts.
Thanks,
Jan