Bug 6169

Trying to create a GS4GT distribution against GT-4.0.6 fails with the error
below.


(vons-mac) /tmp/gridshib/gt/dist>ant create-dist
Buildfile: build.xml

...snip...

compile:
    [javac] Compiling 40 source files to
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/build/classes
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
     [copy] Copying 4 files to
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/build/lib
     [copy] Copying 1 file to
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/build/classes
    [javac] Compiling 11 source files to
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/build/classes-old
    [javac]
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/src-proxies/4.0/org/globus/gridshib/BasePIP.java:73:
cannot find symbol
    [javac] symbol  : method isInitialized(java.lang.String)
    [javac] location: interface org.globus.gridshib.gt.authorization.PIP
    [javac]         if (pipImpl().isInitialized(name)) {
    [javac]                    ^
    [javac]
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/src-proxies/4.0/org/globus/gridshib/BasePDP.java:72:
cannot find symbol
    [javac] symbol  : method isInitialized(java.lang.String)
    [javac] location: interface org.globus.gridshib.gt.authorization.PDP
    [javac]         if (pdpImpl().isInitialized(name)) {
    [javac]                    ^
    [javac] 2 errors

BUILD FAILED
/private/tmp/gridshib/gt/dist/build.xml:205: The following error occurred while
executing this line:
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/build.xml:30: The following
error occurred while executing this line:
/private/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/interceptors/java/source/build.xml:316:
Compile failed; see the compiler error output for details.

Total time: 33 seconds

Confirmed that this does work against a GT 4.0.7 install.

Fails against GT 4.0.5 as well, but with a completely different error (see
below). We should decide which of these versions we care about and I can set up
nightly tests against them.

[globus@gridshib-sp ~]$ cd /tmp/gridshib/gt/dist
[globus@gridshib-sp dist]$ export GLOBUS_LOCATION=/usr/local/gt-4.0.5
[globus@gridshib-sp dist]$ ant create-dist
Buildfile: build.xml
...snip...
BUILD FAILED
/tmp/gridshib/gt/dist/build.xml:205: The following error occurred while
executing this line:
/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/build.xml:28: The following error
occurred while executing this line:
/tmp/gridshib/gt/dist/gridshib-gt-0_6_0-src/common/schema/build.xml:39: The
following error occurred while executing this line:
java.io.FileNotFoundException:
/usr/local/gt-4.0.5/share/globus_wsrf_common/build-packages.xml (No such file
or directory)

There are no problems building GS4GT tarballs on the following platforms:

JWS Core 4.0.7 (Win/UNIX)
JWS Core 4.0.6 (Win)
GT 4.0.1 (UNIX)

I have independently confirmed that the build fails on GT 4.0.6 (UNIX) with the
same error message reported by Von in Comment #1.

OK, what is happening is that the errors are caused when one tries to use a GT
deployment that has a old version of GS4GT deployed in it.

Looking at the code that was failing, the isInitialized() that is causing the
problem was added in response to
http://bugzilla.globus.org/globus/show_bug.cgi?id=5544

For more details, see:
http://bugzilla.globus.org/globus/show_bug.cgi?id=5549

So the old version of GS4GT (0.6.0-alpha in this case) didn't have the
isInitialized() method.

The correct solution here is to undeploy gs4gt first, but this has to be done
using the same version of GS4GT as was deployed (i.e. you can't undeploy an old
version with a new version).

Here's a workaround to undeploy old gridshib jars:
% cd $GLOBUS_LOCATION
% find . -name gridshib\*.jar -exec rm {} \;

I'm leaving this bug open, but dropping it to minor. We  should improve our
undeployment to undeploy any old versions that may be deployed.

The current undeploy uses the GAR undeploy process which essentially can only
remove whatever jars were put in (I assume this problem is coming from named
jars).  If the source directory is always available, there could be something
in the ant script that scans for old jars (and maybe even scans for conflicting
jars before deployment, even if undeploy was not called).

Nothing like .so symlink conventions in the java world :-(

(just to be clear: the current GAR system is maintained by the Java core team)

Perhaps we should address this as a documentation issue?

(In reply to comment #6)
> If the source directory is always available, there could be something
> in the ant script that scans for old jars (and maybe even scans for conflicting
> jars before deployment, even if undeploy was not called).

Yes, but what would it do if it found conflicting JARs?  Seems risky to delete
the JARs manually yet leave the other bits and pieces of the deployment in
place.

Currently the undeploy target invokes undeployGar for ${package.name} where
${package.name} is defined as

<property name="package.name"
          value="${base.package.name}-${gs4gt.version}"/>

Isn't the correct solution to call undeployGar for any package in
etc/globus_packages whose name has prefix ${base.package.name} (assuming the
base package name remains constant from version to version)?  I'm not sure how
to make that happen, but it seems safer than hacking the JAR files (which are
but one piece of the puzzle).

(In reply to comment #8)
> Perhaps we should address this as a documentation issue?

Currently an old deployment can be undeployed if the old source directory is
still available.  If a user knew the precise version number of the old
deployment, it might be possible to undeploy the old deployment using the
scripts in the new source directory, but I haven't tried this.

Things get real hairy when we start thinking about automated deployments.  How
will a TeraGrid RP upgrade its GS4GT deployment, for example?  The CTSS scripts
must detect an old deployment, undeploy it, and deploy the new version.  This
implies an automated process of some kind.

(In reply to comment #9) 
> Isn't the correct solution to call undeployGar for any package in
> etc/globus_packages whose name has prefix ${base.package.name} (assuming the
> base package name remains constant from version to version)?  I'm not sure how
> to make that happen, but it seems safer than hacking the JAR files (which are
> but one piece of the puzzle).

Yeah, that sounds like a much better idea.

(In reply to comment #11)
> 
> Yeah, that sounds like a much better idea.

I have no idea how to do this with ant, however.  If anyone has any ideas, let
me know.

(In reply to comment #12)
> I have no idea how to do this with ant, however.  If anyone has any ideas, let
> me know.

Something like the following?

<target name="undeploy-all-gridshib-jars">
  <delete>
    <fileset dir="${globusLocation}/lib" includes="gridshib-gt-*.jar"/>
  </delete>
</target>

Ah, I misread Tim's note. What I suggest is a quick and dirty way of doing
things...

(In reply to comment #13)
> 
> <target name="undeploy-all-gridshib-jars">
>   <delete>
>     <fileset dir="${globusLocation}/lib" includes="gridshib-gt-*.jar"/>
>   </delete>
> </target>

I think you see this now, but this only deletes the JAR files, it doesn't
undeploy the GAR.  Look in $G_L/etc/globus_packages/gridshib*.  Every such
undeploy.xml should be called.  For example, look in common/schema/build.xml:

<target name="undeploy" depends="printDeployed" unless="isNotDeployed">
    <ant antfile="${build.packages}" target="undeployGar">
        <property name="gar.id" value="${package.name}"/>
    </ant>
</target>

I want to call undeployGar on every package with prefix ${base.package.name},
not just ${package.name} (defined in Comment #9).

(In reply to comment #12)
> I have no idea how to do this with ant, however.  If anyone has any ideas, let
> me know.

Perhaps a combination of getting a filelist from globus-packages, ant-contrib's
<foreach> task, and the actual work:

<ant antfile="${build.packages}" target="undeployGar">
    <property name="gar.id" value="${deployment.name}"/>
</ant>

And that pesky "deploy-oldlibs" at the end because of the GAR facility's
inability to do a "put-only" semantic.

(In reply to comment #16)
> (In reply to comment #12)
> > I have no idea how to do this with ant, however.  If anyone has any ideas, let
> > me know.
> 
> Perhaps a combination of getting a filelist from globus-packages, ant-contrib's
> <foreach> task, and the actual work:
> 
> <ant antfile="${build.packages}" target="undeployGar">
>     <property name="gar.id" value="${deployment.name}"/>
> </ant>

Yes, that's exactly what I did.  Here are some details (since this could be
generally useful):

- Installed ant-contrib-1.0b3.jar in a new top-level lib directory (which has
no effect on the actual deployment into $GLOBUS_LOCATION):

<taskdef resource="net/sf/antcontrib/antlib.xml">
    <classpath>
        <pathelement location="lib/ant-contrib-1.0b3.jar"/>
    </classpath>
</taskdef>

- Implemented a new "undeploy-all-versions" target:

<property environment="env"/>
<property name="deploy.dir" location="${env.GLOBUS_LOCATION}"/>
<property name="build.packages" location=
    "${deploy.dir}/share/globus_wsrf_common/build-packages.xml"/>

<target name="undeploy-all-versions"
    description="Undeploy all versions of all GridShib for GT packages">
    <foreach param="path.element" target="undeploy-package">
        <path>
            <dirset dir="${deploy.dir}/etc/globus_packages">
                <include name="gridshib*"/>
            </dirset>
        </path>
    </foreach>
</target>

<target name="undeploy-package">
    <basename property="package.name" file="${path.element}"/>
    <echo message="Undeploying ${package.name}"/>
    <ant antfile="${build.packages}" target="undeployGar">
        <property name="gar.id" value="${package.name}"/>
    </ant>
</target>

- The trick was to apply the <basename> task to the ${path.element} in the
"undeploy-package" target.

(In reply to comment #16)
> 
> And that pesky "deploy-oldlibs" at the end because of the GAR facility's
> inability to do a "put-only" semantic.

This is no longer an issue since we've removed the JAR file dependencies in
GS4GT (Bug 6218).

Committed all resources to CVS HEAD.  This new feature will be distributed with
GS4GTv0.6.1RC2.