I understand that this work-around is not very attractive however I am unable
to find any better way of doing it. First, containers do not expose this type
of information (e.g. container ports) at start up, and second, if it did how do
we determine which port is the right/preferred one?

Let me know if you have any suggestions for this issue.

If you could find out a list of connectors, then simply (randomly) selecting
one would be fine as it would always be correct, whereas the current approach
is always incorrect under any deployment other than https/8843.  If someone
wanted to  specifically choose a specific connector when there are many, than
the current configuration point of manually specifying the defaults seems
sufficient to me.  I think the current approach provides sufficient
configuration points, the issue is that it doesn't provide correct default
behavior.

If you do not have access to all the connector information, do you at least
have access to whether or not https is being used?  If you did, you could at
least provide proper defaults/guesses for http/https.  That is, the major issue
with the current approach is that if you are running the standard non-https
(http/8080), it defaults to https/8443.  It would be nice to at least be able
to default to https/8443 when running secure and http/8080 when not.

In absence of any API to extract the information, a reasonable solution would
be to add the necessary parameters (described in the work around), during the
Globus tomcat deployment process.  That is, when Globus is deployed using the
ant script: ant -f share\globus_wsrf_common\tomcat\tomcat.xml
deployTomcat|deploySecureTomcat you should add http/8080 or https/8443 params
respectively to the copied web.xml.  This would be simple to add as "replace
tokens" in the ant copy.  This would atleast yeild the proper behavior for the
standard deployments.  If the client then changed tomcat to run under a
different configuration, the documentation should just inform them to also edit
web.xml appropriately.

A last resport and hackish solution (that is probably a bad idea) if this
information is not available would be to parse the web.xml directly.

In any event, the API should have a status available (or throw an exception)
that indicates whether the values can be trusted (i.e. were available from the
container itself, or explicitly provided as init params).  The issue currently
is that information that is known to be correct, and information that was a
blind guess is indistinguishable in the API.

So to summarize, my recommendations are:
1) See what, if any information is available from the container.  I'm not
really a servlet expert, so I'm not much help here.
2) If you are unable to determine anything useful from the container at
runtime, address the issue in the Globus deployment to Tomcat.
3) Add something to the ServiceHost API to allow the client to determine if the
information can be trusted to be correct, or if it is just returning an assumed
answer.

The following changes have been made to trunk:

1) The defaultProtocol and defaultPort parameters will be added to the web.xml
during deployment. Their values will default to the deployment option. That is,
if 'deployTomcat' was used, the values will default to http/8080 and if
'deploySecureTomcat' was used, the values will default to https/8443.

2) Also, added 'setDefaults' Ant task to re-configure the defaultProtocol and
defaultPort parameters after deployment. See 4.2.1 in
http://www.globus.org/toolkit/docs/development/4.2-drafts/common/javawscore/admin/index.html#javawscore-admin-tomcat-deploying

Created an attachment (id=1076) [details]
Adds the 'setDefaults' Ant task in tomcat.xml deployment script

Patch to GT 4.0.x that adds the 'setDefaults' Ant task in tomcat.xml deployment
script.

This sounds great.  Thanks!