Solved

Incompatible Java class version for Websphere Application Server

Posted on 2013-01-18
44
3,102 Views
Last Modified: 2013-01-25
Good day experts

I'm having some problems I can't seem to understand...

I just deployed an application (.ear file) the devs delivered, using Websphere version 6.1.0.37, but I'm getting the following message:

==================================================================
java.lang.UnsupportedClassVersionError: com/ProdJva_01 (Unsupported major.minor version 49.0)
      at java.lang.ClassLoader.defineClass0(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
      at com.sap.engine.services.deploy.server.ApplicationLoader.defineClassWithInterception(ApplicationLoader.java:168)
      at com.sap.engine.services.deploy.server.ApplicationLoader.loadLocalClass(ApplicationLoader.java:140)
      at com.sap.engine.frame.core.load.ResourceLoader.loadClass(ResourceLoader.java:143)
==================================================================

I investigated some docs, and from what I understood is because the the class was compiled with a version not compatible for this JVM Websphere is using.

I went to the Websphere's AppServer's JVM and executed the following to get the current JVM version:
==============================================================
opt/IBM/WebSphere/AppServer/java/bin # ./java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxz64devifx-20101008a (SR12 FP2 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxz6423ifx-20101008 (JIT enabled)
J9VM - 20101007_66049_BHdSMr
JIT  - 20100623_16197ifx1_r8
GC   - 20100211_AA)
==============================================================

I then ran javap -verbose against the conflicting program:

===============================================================
home/stmf/IBM/WebSphere/AppServer/java/bin/javap -verbose ProdJva_01
Compiled from "ProdJva_01java"
public class com.ProdJva_01 extends javax.servlet.http.HttpServlet
  SourceFile: "ProdJva_01java"
  RuntimeVisibleAnnotations: length = 0xE
   00 01 00 FFFFFFF6 00 01 00 FFFFFFF7 5B 00 01 73 00 FFFFFFF8
  minor version: 0
 major version: 49
  Constant pool:
================================================================

I then checked what's the major version is about...and it seems that it's version 5...so it should be compatible with my Websphere's JVM...right? I can't get it.

Is there something I'm still missing? :S!!
0
Comment
Question by:Arrismog
  • 16
  • 15
  • 9
  • +1
44 Comments
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795625
49 = 1.5, I can confirm.

There's one step missing in your diagnosis though.  
Have you double checked that Websphere is actually using /opt/IBM/WebSphere/AppServer/java/bin/java ?

Chances are it will spit out the version number of java upon startup.  Otherwise inspect the startup scripts (if nothing obvious, echo the PATH and JAVA_HOME from within the startup script)
0
 

Author Comment

by:Arrismog
ID: 38795732
@tvedtem

Good suggestion, already checked under startServer.log and yes, confirming that I'm running JVM 1.5:

************ Start Display Current Environment ************
Host Operating System is Linux, version 2.6.16.60-0.54.5-default
Java version = J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxz6423ifx-20101008 (JIT enabled)
J9VM - 20101007_66049_BHdSMr
JIT  - 20100623_16197ifx1_r8
GC   - 20100211_AA, Java Compiler = j9jit23, Java VM name = IBM J9 VM
was.install.root = /opt/IBM/WebSphere/AppServer
user.install.root = /opt/IBM/WebSphere/AppServer/profiles/AppSrv01
Java Home = /opt/IBM/WebSphere/AppServer/java/jre
ws.ext.dirs = /opt/IBM/WebSphere/AppServer/java/lib:/opt/IBM/WebSphere/AppServer/classes:/opt/IBM/WebSphere/AppServer/lib:/opt/IBM/WebSphere/AppServer/installedChannels:/opt/IBM/WebSphere/AppServer/lib/ext:/opt
/IBM/WebSphere/AppServer/web/help:/opt/IBM/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime
Classpath = /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties:/opt/IBM/WebSphere/AppServer/properties:/opt/IBM/WebSphere/AppServer/lib/startup.jar:/opt/IBM/WebSphere/AppServer/lib/bootstrap.jar:/opt/IBM
/WebSphere/AppServer/lib/j2ee.jar:/opt/IBM/WebSphere/AppServer/lib/lmproxy.jar:/opt/IBM/WebSphere/AppServer/lib/urlprotocols.jar:/opt/IBM/WebSphere/AppServer/java/lib/tools.jar
Java Library path = /opt/IBM/WebSphere/AppServer/java/jre/bin:/opt/IBM/WebSphere/AppServer/bin::/usr/lib
Current trace specification = *=info
************* End Display Current Environment *************

Any other ideas? :S
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795742
Just to be really, really sure.

Check what's in
/opt/IBM/WebSphere/AppServer/java/jre
(since this is different to /opt/IBM/WebSphere/AppServer/java/bin)

Double check the actual command (in the startup script) which starts the server 'e.g starting /../java...'

(this is just in case the line that prints 'Java version = ' is different to the line which starts the server)
0
 

Author Comment

by:Arrismog
ID: 38795768
@tvedtem:

Checking the contents of /opt/IBM/WebSphere/AppServer/java/jre:
==============================================
server#:/opt/IBM/WebSphere/AppServer/java/jre # ls -l
total 24
drwxr-xr-x 6 root root 4096 Mar 28  2012 ./
drwxr-xr-x 7 root root 4096 Mar 28  2012 ../
drwxr-xr-x 2 root root 4096 Mar 28  2012 .systemPrefs/
drwxr-xr-x 5 root root 4096 Mar 28  2012 PolicyDirector/
drwxr-xr-x 7 root root 4096 Mar 28  2012 bin/
drwxr-xr-x 9 root root 4096 Mar 28  2012 lib/
==============================================

Executing the java version of that directory outputs :
==============================================
server/opt/IBM/WebSphere/AppServer/java/jre # bin/java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxz64devifx-20101008a (SR12 FP2 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxz6423ifx-20101008 (JIT enabled)
J9VM - 20101007_66049_BHdSMr
JIT  - 20100623_16197ifx1_r8
GC   - 20100211_AA)
JCL  - 20101008
==============================================


I also checked why was another java under /opt/IBM/WebSphere/AppServer/java/bin, but it appears that IBM Websphere installation created a symbolic link to /opt/IBM/WebSphere/AppServer/java/jre, so, they are pointing to the same JVM:

==============================================
server:/opt/IBM/WebSphere/AppServer/java/bin # l java
lrwxrwxrwx 1 root root 15 Mar 28  2012 java -> ../jre/bin/java*
==============================================


Also cleared SystemOut.log, stopped the Application Server, and started it to check the initial logs, and found the following:

==============================================
************ Start Display Current Environment ************
WebSphere Platform 6.1 [ND 6.1.0.37 cf371109.05]  running with process name mtynappNode01Cell\mtynappNode01\ser
ver1 and process id 24200
Detailed IFix information: Please use the versionInfo command to view this information
Host Operating System is Linux, version 2.6.16.60-0.54.5-default
Java version = 1.5.0, Java Compiler = j9jit23, Java VM name = IBM J9 VM
was.install.root = /opt/IBM/WebSphere/AppServer
user.install.root = /opt/IBM/WebSphere/AppServer/profiles/AppSrv01
Java Home = /opt/IBM/WebSphere/AppServer/java/jre
ws.ext.dirs = /opt/IBM/WebSphere/AppServer/java/lib:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/classes:/opt
/IBM/WebSphere/AppServer/classes:/opt/IBM/WebSphere/AppServer/lib:/opt/IBM/WebSphere/AppServer/installedChannel
s:/opt/IBM/WebSphere/AppServer/lib/ext:/opt/IBM/WebSphere/AppServer/web/help:/opt/IBM/WebSphere/AppServer/deplo
ytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime
Classpath = /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties:/opt/IBM/WebSphere/AppServer/properties:/
opt/IBM/WebSphere/AppServer/lib/startup.jar:/opt/IBM/WebSphere/AppServer/lib/bootstrap.jar:/opt/IBM/WebSphere/A
ppServer/lib/j2ee.jar:/opt/IBM/WebSphere/AppServer/lib/lmproxy.jar:/opt/IBM/WebSphere/AppServer/lib/urlprotocol
s.jar:/opt/IBM/WebSphere/AppServer/deploytool/itp/batchboot.jar:/opt/IBM/WebSphere/AppServer/deploytool/itp/bat
ch2.jar:/opt/IBM/WebSphere/AppServer/java/lib/tools.jar
Java Library path = /opt/IBM/WebSphere/AppServer/java/jre/bin:/opt/IBM/WebSphere/AppServer/bin::/usr/lib
************* End Display Current Environment *************
=====================================================

So I think that it's really using JVM 1.5 with Websphere 6.1 :S!! Any other ideas :S?

Thanks in advance
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795780
Still need to check the command within the startup script that kicks things off.
0
 

Author Comment

by:Arrismog
ID: 38795805
@tvedtem:

Sorry I didn't catch that part. I use the startServer.sh <serverName> to start the Application Server. The contents of startServer.sh is the following:

=================================================
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # less startServer.sh
#!/bin/sh
WAS_USER_SCRIPT=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/setupCmdLine.sh
export WAS_USER_SCRIPT
/opt/IBM/WebSphere/AppServer/bin/startServer.sh "$@"
=================================================

Which executes /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/setupCmdLine.sh and /opt/IBM/WebSphere/AppServer/bin/startServer.sh.

setupCmdLine.sh has the following, which exports JAVA_HOME variable /opt/IBM/WebSphere/AppServer/java:

==================================================
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # cat /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/setupCmdLine.sh
#!/bin/sh
# @(#) 1.21 CFG/ws/code/profile.templates/src/bin/setupCmdLine.sh, WAS.config.base, WAS61.CFG, b0619.28 5/8/06 13:29:35 [5/12/06 18:34:37]

WAS_USER_SCRIPT="/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/setupCmdLine.sh"
export WAS_USER_SCRIPT
USER_INSTALL_ROOT="/opt/IBM/WebSphere/AppServer/profiles/AppSrv01"
WAS_HOME="/opt/IBM/WebSphere/AppServer"
JAVA_HOME="/opt/IBM/WebSphere/AppServer/java"

WAS_CELL=mtynappNode01Cell
WAS_NODE=mtynappNode01

#ulimit -n 10000

OSGI_INSTALL="-Dosgi.install.area=$WAS_HOME"
OSGI_CFG="-Dosgi.configuration.area=$USER_INSTALL_ROOT/configuration"

ITP_LOC="$WAS_HOME"/deploytool/itp
CONFIG_ROOT="$USER_INSTALL_ROOT"/config

CLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:"$USER_INSTALL_ROOT"/properties/sas.client.props
STDINCLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:"$USER_INSTALL_ROOT"/properties/sas.stdinclient.props
SERVERSAS=-Dcom.ibm.CORBA.ConfigURL=file:"$USER_INSTALL_ROOT"/properties/sas.server.props
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:"$USER_INSTALL_ROOT"/properties/soap.client.props
JAASSOAP=-Djava.security.auth.login.config="$USER_INSTALL_ROOT"/properties/wsjaas_client.conf
CLIENT_CONNECTOR_INSTALL_ROOT="$USER_INSTALL_ROOT"/installedConnectors
CLIENTSSL=-Dcom.ibm.SSL.ConfigURL=file:"$USER_INSTALL_ROOT"/properties/ssl.client.props
WAS_LOGGING="-Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true"

QUALIFYNAMES=-qualifyHomeName
PATH="$JAVA_HOME"/ibm_bin:"$JAVA_HOME"/bin/:"$JAVA_HOME"/jre/bin:$PATH
WAS_EXT_DIRS="$JAVA_HOME"/lib:"$WAS_HOME"/classes:"$WAS_HOME"/lib:"$WAS_HOME"/installedChannels:"$WAS_HOME"/lib/ext:"$WAS_HOME"/web/help:"$ITP_LOC"/plugins/com.ibm.etools.ejbdeploy/runtime
WAS_CLASSPATH="$WAS_HOME"/properties:"$WAS_HOME"/lib/startup.jar:"$WAS_HOME"/lib/bootstrap.jar:"$WAS_HOME"/lib/j2ee.jar:"$WAS_HOME"/lib/lmproxy.jar:"$WAS_HOME"/lib/urlprotocols.jar:"$JAVA_HOME"/lib/tools.jar

PLATFORM=`/bin/uname`
case $PLATFORM in

  AIX)

    WAS_LIBPATH="$WAS_HOME"/bin
    NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/en_US/%N:${NLSPATH:=}
#    WAS_BOOTCLASSPATH=
    ;;

  Linux)

    WAS_LIBPATH="$WAS_HOME"/bin
    NLSPATH=/usr/lib/locale/%L/LC_MESSAGES/%N:${NLSPATH:=}
    JAVA_HIGH_ZIPFDS=200
#    WAS_BOOTCLASSPATH=
    ;;

  SunOS)

    if [ "$LANG" = "" ]
    then
       LANG=C
       export LANG
    fi
    WAS_LIBPATH="$WAS_HOME"/bin
    NLSPATH=/usr/lib/locale/%L/LC_MESSAGES/%N:${NLSPATH:=}
#    WAS_BOOTCLASSPATH=
    ;;

  HP-UX)

    WAS_LIBPATH="$WAS_HOME"/bin
    NLSPATH=/usr/lib/nls/msg/%L/%N:${NLSPATH:=}
#    WAS_BOOTCLASSPATH=
    ;;

  *)

    WAS_LIBPATH="$WAS_HOME"/bin
    NLSPATH=/usr/lib/locale/%L/LC_MESSAGES/%N:${NLSPATH:=}
#    WAS_BOOTCLASSPATH=
    ;;

esac

export PATH WAS_HOME WAS_CELL WAS_NODE JAVA_HOME ITP_LOC CLIENTSAS CLIENTSSL STDINCLIENTSAS SERVERSAS CLIENTSOAP CLIENT_CONNECTOR_INSTALL_ROOT WAS_LOGGING QUALIFYNAMES WAS_EXT_DIRS WAS_CLASSPATH CONFIG_ROOT NLSPATH JAVA_HIGH_ZIPFDS WAS_LIBPATH OSGI_INSTALL OSGI_CFG

========================================================




/opt/IBM/WebSphere/AppServer/bin/startServer.sh on the other hand, has the following, which uses JAVA_HOME variable:

========================================================
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # cat /opt/IBM/WebSphere/AppServer/bin/startServer.sh
#!/bin/sh

# All Rights Reserved * Licensed Materials - Property of IBM
# 5724-I63, 5724-H88, 5655-N01, 5733-W60 (C) COPYRIGHT International Business Machines Corp., 1997,2005
# US Government Users Restricted Rights - Use, duplication or disclosure
# restricted by GSA ADP Schedule Contract with IBM Corp.

# Configuration Based Server Launcher

# Launch Arguments:
#
# serverName     - the name of the server process to be launched.
# -script [script_file_name]
# -nowait
# -quiet
# -trace
# -timeout <time>
# -statusport <port>
#

set_script_executable()
{
  scriptfile=start_$1.sh
  while [ "$#" -gt "0" ]
  do
    # check for -script option
    if [ "$1" = "-script" ]
    then
       # check the next argument for explicit script name
       if [ $# -gt "1" ]
       then
          shift
          # if the argument begins with "-", ignore it
          # because it is not a script file name
          if [ `echo "$1" | cut -c 1` != "-" ]
          then
             scriptfile="$1"
          fi
       fi
       # make sure the file does exist before setting exec permission
       if [ -f $scriptfile ]
       then
          chmod +x $scriptfile
       fi
    fi
    shift
  done
}


# Bootstrap values ...
SHELL=com.ibm.ws.management.tools.WsServerLauncher

binDir=`dirname $0`
. $binDir/setupCmdLine.sh

#The following is added through defect 236497.1
CMD_NAME=`basename $0`

if [ -f ${JAVA_HOME}/bin/java ]; then
    JAVA_EXE="${JAVA_HOME}/bin/java"
else
    JAVA_EXE="${JAVA_HOME}/jre/bin/java"
fi

if [ "${INV_PRF_SPECIFIED:=}" != "" ] && [ "$INV_PRF_SPECIFIED" = "true" ]
then
    ${JAVA_EXE} -cp "${WAS_HOME}/lib/commandlineutils.jar" com.ibm.ws.install.commandline.utils.CommandLineUtils -specifiedProfileNotExists -profileName $WAS_PROFILE_NAME
    exit 1
elif [ "${WAS_USER_SCRIPT_FILE_NOT_EXISTS:=}" != "" ] && [ "$WAS_USER_SCRIPT_FILE_NOT_EXISTS" = "true" ]
then
    ${JAVA_EXE} -cp "${WAS_HOME}/lib/commandlineutils.jar" com.ibm.ws.install.commandline.utils.CommandLineUtils -wasUserScriptFileNotExists -wasUserScript $WAS_USER_SCRIPT
    exit 1
elif [ "${NO_DFT_PRF_EXISTS:=}" != "" ] && [ "$NO_DFT_PRF_EXISTS" = "true" ]
then
    ${JAVA_EXE} -cp "${WAS_HOME}/lib/commandlineutils.jar" com.ibm.ws.install.commandline.utils.CommandLineUtils -noDefaultProfile -commandName $CMD_NAME
    exit 1
fi

# For debugging the launcher itself
# WAS_DEBUG="-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"

#zOS
# "$JAVA_HOME"/bin/java -Dfile.encoding=ISO8859-1 -Xnoargsconversion \
#   $DEBUG \
#   -Dws.ext.dirs="$WAS_EXT_DIRS" \
#    $CONSOLE_ENCODING \
#   -Djava.ext.dirs="$JAVA_EXT_DIRS" \
#   -classpath "$WAS_CLASSPATH" \
#   -Dwas.install.root="$WAS_HOME" \
#   -Dwas.serverstart.cell="$WAS_CELL" \
#   -Dwas.serverstart.node="$WAS_NODE" \
#   -Dwas.serverstart.server="$1" \
#   $USER_INSTALL_PROP \
#   $JVM_EXTRA_CMD_ARGS \
#   com.ibm.ws.bootstrap.WSLauncher \
#   $SHELL "$CONFIG_ROOT" "$WAS_CELL" "$WAS_NODE" "$@"

#ASV
# "$JAVA_HOME"/bin/java \
#   $DEBUG \
#   -Dws.ext.dirs="$WAS_EXT_DIRS" \
#   -classpath "$WAS_CLASSPATH" \
#   -Dwas.install.root="$WAS_HOME" \
#   $USER_INSTALL_PROP \
#   com.ibm.ws.bootstrap.WSLauncher \
#   $SHELL "$CONFIG_ROOT" "$WAS_CELL" "$WAS_NODE" "$@"

# Setup the initial java invocation;
DELIM=" "

#Platform specific args...
PLATFORM=`/bin/uname`

if [ "$PLATFORM" = "OS/390" ] && [ ! -e "$WAS_HOME/properties/service/product/WebSphere/backup/396435/defect.applied" ]
then
    WAS_EXT_DIRS="$WAS_EXT_DIRS:$WAS_SMPE_ROOT/plugins"
fi

#Common args...
D_ARGS="-Dws.ext.dirs="$WAS_EXT_DIRS" $DELIM -Dwas.install.root="$WAS_HOME" $DELIM -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager $DELIM -Djava.util.logging.configureByServer=true"

case $PLATFORM in
  AIX)
    EXTSHM=ON
    LIBPATH="$WAS_LIBPATH":$LIBPATH
    export LIBPATH EXTSHM ;;
  Linux)
    LD_LIBRARY_PATH="$WAS_LIBPATH":$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH ;;
  SunOS)
    LD_LIBRARY_PATH="$WAS_LIBPATH":$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH ;;
  HP-UX)
    SHLIB_PATH="$WAS_LIBPATH":$SHLIB_PATH
    export SHLIB_PATH ;;
  OS/390)
    PATH="$PATH":$binDir
    export PATH
    D_ARGS=""$D_ARGS" $DELIM -Dfile.encoding=ISO8859-1 $DELIM -Djava.ext.dirs="$JAVA_EXT_DIRS""
    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.cell="$WAS_CELL""
    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.node="$WAS_NODE""
    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.server="$1""
    X_ARGS="-Xnoargsconversion" ;;
esac

PATH=${WAS_DB2_PATH_VAR:+"$WAS_DB2_PATH_VAR":}"$PATH"
export PATH

"$JAVA_HOME"/bin/java \
  "$OSGI_INSTALL" "$OSGI_CFG" \
  $X_ARGS \
  $WAS_DEBUG \
  $CONSOLE_ENCODING \
  $D_ARGS \
  -classpath "$WAS_CLASSPATH" \
  $USER_INSTALL_PROP \
  $JVM_EXTRA_CMD_ARGS \
  com.ibm.ws.bootstrap.WSLauncher \
  $SHELL "$CONFIG_ROOT" "$WAS_CELL" "$WAS_NODE" "$@" $WORKSPACE_ROOT_PROP

launchExit=$?
if [ "$launchExit" = "0" ]
then
  set_script_executable $@
fi
exit `expr $launchExit + $?`
========================================================

I'm still seeing the correct environment variables (from what I understand from those scripts)... :S ! Any other ideas?

Thanks in advance
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795813
Fairly sure this won't be different, but in cases like this I find it's best to be 100% sure !

If you can, amend the startServer.sh script adding the line
echo ${JAVA_EXE}

immediately below this bit

if [ -f ${JAVA_HOME}/bin/java ]; then
    JAVA_EXE="${JAVA_HOME}/bin/java"
else
    JAVA_EXE="${JAVA_HOME}/jre/bin/java"
fi

Open in new window



And then do a /..../java -v
 (using the full path of whatever it spits out instead of ....)

At that point, there's nothing more we can do to check the WS java version, so attention will turn to the java file !
0
 

Author Comment

by:Arrismog
ID: 38795832
@tvedtem:

Nice suggestion to validate JVM, tried as suggested and got (added echo "JAVA_EXE path >>>${JAVA_EXE}" ) :

========================================================
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # ./startServer.sh server1
JAVA_EXE path >>>/opt/IBM/WebSphere/AppServer/java/bin/java
ADMU0116I: Tool information is being logged in file
           /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/startServer.log
ADMU0128I: Starting tool with the AppSrv01 profile
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 24588
==========================================================

I then ran /opt/IBM/WebSphere/AppServer/java/bin/java -version :

==========================================================
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # /opt/IBM/WebSphere/AppServer/java/bin/java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxz64devifx-20101008a (SR12 FP2 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxz6423ifx-20101008 (JIT enabled)

J9VM - 20101007_66049_BHdSMr
JIT  - 20100623_16197ifx1_r8
GC   - 20100211_AA)
JCL  - 20101008
==========================================================

Confirming that I'm running JVM 1.5 with the AppServer, that was a good suggestion. Now I guess that the problem is with the java file right? :S
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795867
One last thing - (sorry I missed this the first time)

Add these lines:

echo $PATH
echo "$JAVA_HOME"/bin/java \
  "$OSGI_INSTALL" "$OSGI_CFG" \
  $X_ARGS \
  $WAS_DEBUG \
  $CONSOLE_ENCODING \
  $D_ARGS \
  -classpath "$WAS_CLASSPATH" \
  $USER_INSTALL_PROP \
  $JVM_EXTRA_CMD_ARGS \"

Immediately below
export PATH

(since that last line is actually the line that starts WSLauncher)
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795872
(also worth a look in ibm_bin)
0
 

Author Comment

by:Arrismog
ID: 38795908
@tvedtem:

Appending the contents of variables (added ===Starting echo variables=== and =======):


===Starting echo variables====
/opt/IBM/WebSphere/AppServer/java/ibm_bin:/opt/IBM/WebSphere/AppServer/java/bin/:/opt/IBM/WebSphere/AppServer/java/jre/bin:/opt/IBM/WebSphere/AppServer/java/ibm_bin:/opt/IBM/WebSphere/AppServer/java/bin/:/opt/IBM/WebSphere/AppServer/java/jre/bin:/sbin:/usr/sbin:/usr/local/sbin:/opt/gnome/sbin:/root/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
/opt/IBM/WebSphere/AppServer/java/bin/java -Dosgi.install.area=/opt/IBM/WebSphere/AppServer -Dosgi.configuration.area=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration -Dws.ext.dirs=/opt/IBM/WebSphere/AppServer/java/lib:/opt/IBM/WebSphere/AppServer/classes:/opt/IBM/WebSphere/AppServer/lib:/opt/IBM/WebSphere/AppServer/installedChannels:/opt/IBM/WebSphere/AppServer/lib/ext:/opt/IBM/WebSphere/AppServer/web/help:/opt/IBM/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime -Dwas.install.root=/opt/IBM/WebSphere/AppServer -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true -classpath /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties:/opt/IBM/WebSphere/AppServer/properties:/opt/IBM/WebSphere/AppServer/lib/startup.jar:/opt/IBM/WebSphere/AppServer/lib/bootstrap.jar:/opt/IBM/WebSphere/AppServer/lib/j2ee.jar:/opt/IBM/WebSphere/AppServer/lib/lmproxy.jar:/opt/IBM/WebSphere/AppServer/lib/urlprotocols.jar:/opt/IBM/WebSphere/AppServer/java/lib/tools.jar -Duser.install.root=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01 "
================================

I also checked /opt/IBM/WebSphere/AppServer/java/ibm_bin but there's no directory with that name, so I guess it goes to the next variable /opt/IBM/WebSphere/AppServer/java/bin/
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38795956
OK, thanks for that.

Regarding the PATH, you're correct that it will be searched in order until something is found - however in this case the line that actually starts WS uses a fully qualified file and so won't be dependent on PATH

(that is.. /opt/IBM/WebSphere/AppServer/java/bin/java -Dosgi.install.area...)

Had it begun with 'java -D...', you'd be dependent on PATH.


You'd established earlier that /opt/IBM/WebSphere/AppServer/java/bin/java is 1.5, so we have now double & triple checked it !

The error you're getting would be typical of attempting to run 1.5 bytecode on a 1.4 (say) JVM, so this is a little mysterious.

Anything interesting in
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties
?

The error message you're getting refers to:
 com.sap.engine.services.deploy.server.ApplicationLoader
so I am beginning to wonder whether this is actually some SAP related issue.

I don't know anything about SAP, but could there be some compatibility issue there ?

If not you might have to bat it back to the developer...
0
 
LVL 86

Assisted Solution

by:CEHJ
CEHJ earned 250 total points
ID: 38796200
so I am beginning to wonder whether this is actually some SAP related issue.
Possibly with SAP trying to load a subsidiary jvm which IS lower < 1.5 ..? That would then account for the binary incompatibility message
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38796208
Yes I would think quite likely.
0
 

Author Comment

by:Arrismog
ID: 38796239
I'm pretty lost with SAP...is this part of Websphere? Is there any way to check the version of this "subsidiary jvm" or is it part of the ear file itself?
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38796253
Well don't ask me - i know neither SAP nor WS ;) But you could for instance start looking for shared libraries or dlls in the SAP directories. If you find any - get more suspicious ;) THIS looks of interest
0
 
LVL 34

Expert Comment

by:Gary Patterson
ID: 38796639
Are you showing the whole stacktrace?  Looks to me if there is a version mismatch it is in the SAP classes.  I wonder if there is a SAP class compiled at 1.6 (or newer) in the SAP classes that is causing the problem?

Reporting version 49 when running 1.5 sure seems wrong.  Wonder if it is possible that the error is correct, but the wrong version string is being reported?  

All indications are that you're running 1.5.  So if the error is correct, a class compiled under 1.5 can't legitimately throw a version error.  To me, this implies three likely options:

1) Error is correct, and somehow you are actually running 1.4 or lower.  Simplest answer, but troubleshooting so far doesn't support this.  

Suggestions:  Is there another JRE even installed on this machine?  If not, you can probably rule out this one.

2) Error is correct, but major code is reported incorrectly, perhaps due to a bug in the JRE?  This would imply that you have a class compiled at 1.6 or higher attempting to load.

Suggestions:  Identify and javap -verbose the SAP class that is causing the error.  Upgrade JRE in WAS to compatible version, or recompile SAP classes or obtain SAP classes compiled to 1.5 or lower.

3) Wrong error is being raised altogether.  Probably lowest likelyhood, but if you eliminate 1 and 2, I think this is what you are left with.

Suggestions:  Engage development team to determine differences between dev environment and the environment where you are installing.  Open incidents with IBM and SAP.  Install IBM Java PTFs.  Upgrade IBM JRE.  Install SAP fixes.

- Gary Patterson
0
 
LVL 34

Expert Comment

by:Gary Patterson
ID: 38796664
Also, SAP is not part of Websphere.  Websphere Application Server (WAS) is IBM's J2EE application server.  

SAP is a company that makes a well-known Enterprise Resource Planning (ERP) software package, plus a lot of associated tools.

Looks like your dev team is developing software that runs in WAS that interfaces with SAP, and is using some SAP-supplied classes for that purpose.
 
- Gary Patterson
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38796688
com/ProdJva_01

Open in new window

You should actually extract that class from wherever it's hiding and check its version so you know exactly where you are. What OS are you using btw?
0
 

Author Comment

by:Arrismog
ID: 38796950
@Gary_The_IT_Pro:

1) No, no other JRE has been installed on the server, so, only the one that comes with Websphere 6.1 is the one running, so this option could be ruled out as you suggest.

2) Yeah, that was another thing I was thinking, so I extracted the class file and ran javap -verbose, and yes, it certainly has a major version=49 :S!!

===============================================================
home/stmf/IBM/WebSphere/AppServer/java/bin/javap -verbose ProdJva_01
Compiled from "ProdJva_01java"
public class com.ProdJva_01 extends javax.servlet.http.HttpServlet
  SourceFile: "ProdJva_01java"
  RuntimeVisibleAnnotations: length = 0xE
   00 01 00 FFFFFFF6 00 01 00 FFFFFFF7 5B 00 01 73 00 FFFFFFF8
  minor version: 0
major version: 49
  Constant pool:
================================================================

3) I have a question with this one about sap...does this "sap" part gets compiled differently from any other "normal" class files from the JVM Websphere's perspective? Are these sap libraries in the server side or are part of the application/ear file just like external jars/classes in their ear's lib directory? What I'm still not getting is why it's reporting a major version that is indeed supported in this jvm websphere version and still says it's not supported :S!!!


@CEHJ
Already extracted the class file and javap -verbose'd it, and yes, it has major version=49
I'm running a SuSE Linux Enterprise Server 10 SP3, with Websphere Application Server 6.1.0.37
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38797275
Already extracted the class file and javap -verbose'd it, and yes, it has major version=49
OK, then i'm tending to think still that there's another lower jvm being created somewhere. You could look for any candidate alternative vms. If you have an up-to-date locate db, you might try

locate -r '/[^/]*java[^/]*\.so$'

Open in new window

0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:Arrismog
ID: 38797396
Don't have locate :(, so did a find if it's of any help:

=================================================
:/ # find / -name "*java*.so"
/opt/kde3/lib/kde3/kjavaappletviewer.so
/opt/kde3/lib64/kde3/kjavaappletviewer.so
/opt/IBM/WebSphere/AppServer/uninstall/java/bin/libjava.so
/opt/IBM/WebSphere/AppServer/uninstall/java/bin/libjava_crw_demo.so
/opt/IBM/WebSphere/AppServer/java/jre/bin/libjava.so
/opt/IBM/WebSphere/AppServer/java/jre/bin/libjava_crw_demo.so
/opt/IBM/WebSphere/UpdateInstaller/uninstall/java/bin/libjava.so
/opt/IBM/WebSphere/UpdateInstaller/uninstall/java/bin/libjava_crw_demo.so
/opt/IBM/WebSphere/UpdateInstaller/java/jre/bin/libjava.so
/opt/IBM/WebSphere/UpdateInstaller/java/jre/bin/libjava_crw_demo.so
/opt/IBM/HTTPServer/uninstall/java/bin/libjava.so
/opt/IBM/HTTPServer/uninstall/java/bin/libjava_crw_demo.so
/opt/IBM/HTTPServer/java/jre/bin/libjava.so
/opt/IBM/HTTPServer/java/jre/bin/libjava_crw_demo.so
/opt/IBM/HTTPServer/Plugins/uninstall/java/bin/libjava.so
/opt/IBM/HTTPServer/Plugins/uninstall/java/bin/libjava_crw_demo.so
/opt/IBM/HTTPServer/Plugins/java/jre/bin/libjava.so
/opt/IBM/HTTPServer/Plugins/java/jre/bin/libjava_crw_demo.so
/usr/lib/xulrunner-1.8.1.21/libjavaxpcomglue.so
/usr/lib64/xulrunner-1.8.1.21/libjavaxpcomglue.so
=================================================

Ran java version from every directory found and all of them are java version "1.5.0" :S!
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38797400
Try a find for sap* and sapjvm*
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38797405
Mysterious...
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38797410
Try a find for sap* and sapjvm*
Ahh
0
 

Author Comment

by:Arrismog
ID: 38797487
@tvedtem:

Hmmm:

mtynapp:~ # find / -name "sap*"
/var/lib/zypp/cache/Source.Ty2dmb/DATA/descr/sap_server-10-51.51.9.s390x.pat
/var/lib/zypp/cache/Source.Ty2dmb/DATA/descr/sap_server-32bit-10-51.51.9.s390x.pat
/var/lib/zypp/cache/Source.NhRQQY/DATA/descr/sap_server-10-51.51.9.s390x.pat
/var/lib/zypp/cache/Source.NhRQQY/DATA/descr/sap_server-32bit-10-51.51.9.s390x.pat

mtynapp:~ # find / -name "sapjvm*"
(no results)
mtynapp:~ #
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38797573
Ok. Well time to unpack the ear file I think.
jar -tvf filename.ear to list its contents.
Or make a copy somewhere temporary and extract with jar -xvf

Obviously speaking to the developer would be a good idea too!
0
 
LVL 34

Expert Comment

by:Gary Patterson
ID: 38798852
http://code.google.com/p/versioncheck/

After you extract the EAR, try scanning it with this tool.  It will group classes together by version.  Once you have run it on the EAR, also run it on the other folders in the classpath.

- Gary
0
 

Author Comment

by:Arrismog
ID: 38803520
@Gary_The_IT_Pro:
Very useful tool! Didn't know it existed at all! Ran the jar version checker and got the following:

Version Checker Tool V1.0

Verified Direcotry : /Users/Yuki/Documents/TELMEX/temporales/STDM_ear.ear

..........................................................................................
Major.Minor Version : 46.0             JAVA compatibility : Java 1.2 platform: 45.3-46.0
Number of classes : 851

Major.Minor Version : 5.3             JAVA compatibility :
Number of classes : 3

Major.Minor Version : 49.0             JAVA compatibility : Java 1.5 platform: 45.3-49.0
Number of classes : 1305

Major.Minor Version : 45.3             JAVA compatibility : Java 1.1 platform: 45.3-45.65535
Number of classes : 1889

.........................................................................................
Total Time : 0 Seconds

I'm seeing only one Java 1.5 major-minor version, and all others are for Java 1.1, Java 1.2...and one that is "blank"...But from what I understand, there should be no problem at all with all of them if my JVM is 1.5 (I guess it should support lower versions right?
0
 

Author Comment

by:Arrismog
ID: 38803549
Ohhh wait, running the verbose mode, I'm getting the following:

=============================================================
Major.Minor Version : 46.0             JAVA compatibility : Java 1.2 platform: 45.3-46.0
Number of classes : 851
=============================================================

Considering that JAVA compatibility shown for those 851 classes is 45.3 - 46.0, and the error is  (Unsupported major.minor version 49.0), should I consider that this is NOT compatible because the compiled versions are within 45.3 - 46.0 range, or Java 1.5 (49.0) should support it?

Another doubt...the error specifically occurs pointing to com/ProdJva_01
=======================================
java.lang.UnsupportedClassVersionError: com/telmex/stdm/serv/Fwstd00a_acc (Unsupported major.minor version 49.0)
=======================================

But checking the output from the tool for that specific class, it is Java 1.5 compiled:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Major.Minor Version : 49.0             JAVA compatibility : Java 1.5 platform: 45.3-49.0
Number of classes : 1305

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Could it be possible that under that class a reference to others from the "old" version is called, hence throwing this message?

From what I understand...the "(Unsupported major.minor version 49.0)" is referencing the version of the compiled program and not the jvm version (?)

Thanks in advance
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38803555
Going back to the original stack trace, it would appear that SAP has its own class loader, which seemingly cannot support 1.5 .    I would've expected to see SAP installed on the server but then nothing showed up with the earlier find. Somebody there should know I guess!   Maybe double check /usr/sap to be sure..  But if there's nothing there then it must be packaged up in the ear file I suppose.

If you send the output of -tvf to a file, try a grep for sap. (-i, to be sure). Or just attach the file here if it's not too large.

EDIT: we crossed paths there. Java 1.2 is 15 years old so something strange is going on! I would imagine it means 1.2+
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38803572
What I'm aiming for above is to find the SAP classes ResourceLoader and ApplicationLoader. They appear to be finding a JVM that is <1.5. At this point my guess is that the developer has unwittingly built you an ear which contains his local version of the java libraries, we'll see from the listing.
0
 

Author Comment

by:Arrismog
ID: 38803650
By sending the output of -tvf, do you mean to include the output of the versioncheck jar to a tar file and attach it?
0
 
LVL 4

Accepted Solution

by:
tvedtem earned 250 total points
ID: 38803827
Just the output of jar -tvf filename.ear for now - (a single text file listing the contents)
Just to find out which files are present, in particular looking for SAP files and/or JVM files.

I'd be interested to know where ResourceLoader and ApplicationLoader are, and whether there are any versions of java.lang.ClassLoader present.
That might well involve performing further extracts on JAR files held within the ear.

We can then check the versions of anything suspicious.
0
 

Author Comment

by:Arrismog
ID: 38807167
@tvedtem

Sir, your suspicions were correct. Had a conference with the devs, and in spite all their sayings that they didn't have any other redirection or modules to another JVM we asked them again to do a complete revision to their programs and, in fact, they were (SAP J2EE, 1.4!!). Thanks for the suggestions of the jar command :)
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38814064
Good news !  Never trust a developer :)
Just as a very general rule-of-thumb.. when deploying to an app server you wouldn't normally supply a JVM (the intention is that the app server supplies it) - same for the j2ee jars.  In this case it appears as though they are packaging it up with the ear.  
Glad you have it sorted now anyway !
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38815345
Possibly with SAP trying to load a subsidiary jvm which IS lower < 1.5 ..? That would then account for the binary incompatibility message
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38816432
Ah -yes CEHJ got there first (or said it first, at least!).  
I read that comment as from Arrismog initially.
Feel free to redistribute points.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38816475
Don't worry about points - it's just nice to know one hasn't wasted  one's time totally .. ;)
0
 
LVL 4

Expert Comment

by:tvedtem
ID: 38816643
I get that feeling often on e-e, as my style is to go in small steps :)
0
 

Author Comment

by:Arrismog
ID: 38816755
@CEHJ :

Sorry CEHJ, you're right, I already requested the mods for the point re-distribution :), again, thanks a lot for all your help. I really appreciate your support :)
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 38818451
I get that feeling often on e-e, as my style is to go in small steps :)
That's a very good style :)
0
 

Author Closing Comment

by:Arrismog
ID: 38819595
@CEHJ and @tvedtem, thanks for all your support :)
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

Verbose logging is used to diagnose garbage collector problems. By default, -verbose:gc output is written to either native_stderr.log or native_stdout.log.   It is also possible to redirect the logs to a user-specified file. This article will de…
This exercise is about for the following scenario: Dmgr and One node with 2 application server. Each application server contains it owns application. Application server name as follows server1 contains app1 server2 contains app1 Prereq…
The viewer will learn how to implement Singleton Design Pattern in Java.
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now