Bug 5569

Using relative paths in the echo service's configuration files is the result of
a balancing act between providing an out of the box configuration file for the
echo service and a good configuration file.

It is (I think) currently our recommendation to never use relative paths for
service configurations -- but with the echo and test service's we wanted to
provide good defaults to get the user going as quickly as possible with the
least chance for errors/confusion.

In general if relative paths are used, the interceptor configurations have an
ambiguous job to do.

For example, one could treat the current working directory (CWD) as the only
place to base relative paths from or alternatively try several known locations
in a certain order.  e.g. 1. CWD, 2. GLOBUS_LOCATION (obtained from environment
or container axis property), 3. /etc/grid-security.  It's my opinion at least
that any list or order here is suboptimal.

The only OK relative path scheme in my opinion is to use CWD only.  It is easy
to explain and in most cases will avoid misconfiguration.  But this restricts
the container to being started from the actual GLOBUS_LOCATION which is not
good for many reasons: 

- detached init.d scripts shouldn't have to worry about CWD
- starting tests from the tests or GS4GT source directory is much more
convenient than finding the ant tests file via the -f parameter from
GLOBUS_LOCATION
- potential ambiguity when the interceptors are running in other containers
such as Tomcat
- etc.

In general, it would be simpler and safer to just require absolute paths.  But
then we could potentially lose the out of the box echo service (and of lesser
importance convenient testing).

I suggest we write the absolute deployment paths into the config files in a
post-deploy task and just require absolute paths across the board.

These are orthogonal things though, we could decide here to write absolute
paths to the echo service's config files (and the end to end test service)
without actually ruling out relative paths for interceptor configurations.

The rest of this bug report deals with the former thing:

Currently the relative paths for the 4.0 echo service come from
deploy-server.wsdd "@config.dir@" replacement.  

The 4.1+ echo service relative paths are hard coded into the example security
descriptor.  Since the version number for the package is part of the package's
$GL/etc directory, this is especially aggravating because a version update
means we need to update that file manually.  See Bug #5194

In the service build steps we could generate the relative portion of the
version-dependent etc directory name using ant's copy+filter capabilities with
a special token.  All we would need to do is change the GAR builder's etc
directory configuration in the ant script from the present etc directory to a
build/etc directory that contains the copy+replaced file(s).

Then in post-deploy, the absolute path to GLOBUS_LOCATION could be appended
into the configurations.  It is important this happens in post-deploy because
that way generated binaries can still be deployed to any $GL.

So there would be two tokens, one used to replace the package name during the
build and one used to replace GLOBUS_LOCATION at deployment.

For example:

OLD 4.0:

<parameter name="secctxecho-gridshibAuthzPolicyFile"
           value="@config.dir@/echo-attr-authz-vo.xml"/>

OLD 4.1:

<param:parameter 
   name="gridshibAuthzPolicyFile"
   value="etc/gridshib-gt-echo-0_6_0-tp4/echo-attr-authz-vo.xml"/>

NEW:

  value="@GS4GT_GL@/etc/@GS4GT_PACKAGENAME@/echo-attr-authz-vo.xml"


The build files replace @GS4GT_PACKAGENAME@ with the right (version embedded)
package name.  The post-deploy task replaces @GS4GT_GL@ with the target
GLOBUS_LOCATION absolute path.