This problem is due to a older version of xerces being on the classpath. If I
remember correctly IBM's jdk ships with this older version of xerces, so you may
have to override that. Jarek, I thought our core docs had a note on this at some
point?

This might have to do with the Java version. I get past this problem on another
AIX 5.2 system, which has the following Java installed:

[ux454281@longhorn globus]$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX build ca142ifx-20041203
(142SR1+80507) (JIT enabled: jitc))


I'm going to ask Java to be upgraded on the first system also, and then I will
know for sure.

This is a problem with IBM JDK 1.4.1 (was able to replicate it on Linux). The 
problem does not happen with JDK 1.3.1 or 1.4.2. The Java WS Core tests did not 
catch this problem as we test with IBM 1.3.1 and 1.4.2 JVMs (but not 1.4.1).
I'll add IBM 1.4.1 to the nightly tests and try to find a workaround for this 
issue. For now you can update to 1.4.2.

There is no way to fix our build system to work out-of-box with IBM JVM 1.4.1 
(at least I cannot find a way). The necessary command line options for the 
compiler are not there or are non-standard. There are two workarounds:

1) Switch to IBM JVM 1.4.2 or 1.3.1.

2) Create $JAVA_HOME/jre/lib/endorsed directory. Copy xercesImpl.jar from GT 
distribution to that directory.

I'll update Java WS Core documentation with this info.


 

Mei and I have seen this same problem building 4.0.0 on a Solaris 5.9 box with
java 1.3.1_01, 1.4.1_01 and 1.4.2_06. These don't seem to be IBM jdks:

java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

Since these are not our installations, we were not able to override the endorsed
jars.

1. Do you see the same exact exception?

2. We have nightly tests running on Solaris 5.9 with all three major versions 
of Sun JVM and everything is fine. So these JDKs must be configured differently 
somehow. Can you send the list of jars (if any) in the jre/lib/endorsed and 
jre/lib/ext directories?

The failure with 1.3.1, 1.4.1 and 1.4.2 are exactly the same.

Additional input from Mei:

dataportal% pwd
/local/j2sdk1.4.2_06
dataportal% ls jre/lib/endorsed
xalan.jar       xercesImpl.jar  xml-apis.jar
dataportal% ls jre/lib/ext
dnsns.jar            ldapsec.jar          localedata.jar
sunjce_provider.jar


The failure with java 1.5 seems to be different though (use of enum):
    [javac]
/home/meihuisu/GLOBUS4/gt4.0.0-all-source-installer/source-
trees/wsrf/java/core/
sourc
e/src/org/globus/axis/description/ServiceDescUtil.java:52: as of release 1.5,
'enum' is a keyword
, and may not be used as an identifier^M
    [javac] (try -source 1.4 or lower to use 'enum' as an identifier)^M
    [javac] import org.apache.axis.enum.Scope;^M
    [javac]                        ^^M
    [javac]
/home/meihuisu/GLOBUS4/gt4.0.0-all-source-installer/source-
trees/wsrf/java/core/source/src/org/globus/axis/providers/RPCProvider.java:24: 
as of release 1.5, 'enum'
is a keyword, and
may not be used as an identifier^M
    [javac] (try -source 1.4 or lower to use 'enum' as an identifier)^M
    [javac] import org.apache.axis.enum.Scope;^M
    [javac]                        ^^M
    [javac]
/home/meihuisu/GLOBUS4/gt4.0.0-all-source-installer/source-
trees/wsrf/java/core/source/src/org/globus/wsrf/impl/ServiceResourceHome.java:1
7: as of release 1.5,
'enum' is a keyword, a
nd may not be used as an identifier^M
    [javac] (try -source 1.4 or lower to use 'enum' as an identifier)^M
    [javac] import org.apache.axis.enum.Scope;^M
    [javac]                        ^^M
    [javac] 3 errors^M
^M
BUILD FAILED^M
file:/home/meihuisu/GLOBUS4/gt4.0.0-all-source-installer/source-
trees/wsrf/java/
core/source/build
.xml:211: Compile failed; see the compiler error output for details.^M
^M
Total time: 1 minute 24 seconds^M

Delete all the jars in the endorsed directory or update them from GT4 
distribution. They do not come with a standard SUN JDK installation (some IBM 
JDKs do). 
Also, with Java 1.5, if you create a simple build.xml with the following 
contents:

<project>
  <echo>os.name = ${os.name}</echo>
  <echo>java.home = ${java.home}</echo>
  <echo>ant.java.version = ${ant.java.version}</echo>
  <echo>java.vendor = ${java.vendor}</echo>
  <echo>java.version = ${java.version}</echo>
</project>

what's the value of ant.java.version? Also, what version of Ant are you using?

We also have tests running with Java 5 (2 different impls) and see no issues.

Btw, just verified, you'll need Ant 1.6.1 to compile things ok with Java 1.5 
(that's the first version of Ant that added 1.5 support).

Hi,
 Before we ask the target site's admin to zap their
jars under their endorsed directory, we need to let
them know what version of those jars are in GT4's 
distribution and whether or not they have been altered 
from their original release. They would then decide
if they are going to update their endorsed directory
and test all their other applications that is affected
by this change.
mei 

Please see http://www-
unix.globus.org/toolkit/docs/4.0/common/javawscore/dependencies.html (this is 
linked from Java WS Core documentation). GT4 uses standard (unmodified) 
distributions of Xalan and Xerces. 
I only meant to remove those jar files for testing only. This is a customized 
JVM installation and you'll either need to update those jar files or get a new 
(fresh) JVM installation.