As the complexity of my web applications increases, I found an incompatibility issue between Tomcat 5.5.9-Windows and Tomcat 5.5.9-z/OS. The same web application successfully runs in Windows but crashes in z/OS. Furthermore, the initial web application page looks different in z/OS.
Here are more details about the web application and how it was ported to z/OS:
1) The web application is: xmlbeans5. I created the xmlbeans5.war file in Windows and copied it to z/OS using Ipswitch WS-FTP into the Tomcat webapps directory. Before copying the war file, I deleted the webapps\xmlbeans5 directory (and sub directories) that Tomcat created in previous tests of the same application.
The difference between the two initial pages seems to come from a previous incarnation of the same web application, which had the following first page:
It looks that some of the Tomcat cache has not been totally cleared when a new copy of the application was added. I do not have the same problem in Windows.
4) In z/OS the web application crashes with a NullPointer exception. I was not able to look at the Tomcat log file; the Tomcat logs directory is empty… The full error message can be found in the last execution of Steve's Tomcat job (BOVST01.EINSTALL.JZOS.JCL(TC14)).
5) The 3.1 version of Eclipse running under Windows does not allow you to define an additional server (Tomcat or otherwise) : the z/OS server. To debug the web application in z/OS, I start the local Tomcat server, point to the http://usilca11:8085/xmlbeans5/ application and I can see the first web page. However, when I click on the 'Say Hello' button, control does not see the breakpoint I set a the beginning of the application -- I cannot debug the z/OS web application to discover where the application crashes. Using the same technique, control successfully stops at all the breakpoints I have set.
Since I can successfully run the web application in Windows, I followed the same procedure to port the web application to z/OS. I do not know whether Tomcat 5.5.9 in z/OS requires some additional steps that I have not performed…
Other web applications that I have built run successfully in Windows also run successfully in z/OS.
I am running out of ideas on how to debug the faulty web application on z/OS.
help debugging ??
So, do you have problems if you don't hot-deploy? (restart Tomcat after uploading your web app)
The best way to hot-deploy to Tomcat on z/OS, IMO is to use the Tomcat-supplied ant tasks. We did a demo of this at SHARE last week, and we hope to release a sample project and documentation to the web site real soon. The Tomcat "deploy" ant task basically uploads the war file over an http session (into the Tomcat "manager" application), which redeploys it. Really cool...
As far as debugging, you can use the Eclipse JPDA debugger to remotely debug a z/OS application, including Tomcat. You need to start the JVM with the normal JPDA debugging switches that causes it to listen on some port. Then in Eclipse, you can create a Debugger launch configuration for a "Remote Java Application", specifying the hostname/ip address and port to connect to. z/OS Java works just like any remote JPDA target...
You might not need to resort to remote debugging...you should be getting a Java stack trace in the Tomcat log. Unless JITed, you should should be able to see source code line numbers of the methods in the stack below your NPE.
BTW: we haven't done any testing of Tomcat 5.5.x (only up through 5.0.28). Has anyone else used Tomcat 5.5 on z/OS?
The best way to hot-deploy to Tomcat on z/OS, IMO is to use the Tomcat-supplied ant tasks. We did a demo of this at SHARE last week, and we hope to release a sample project and documentation to the web site real soon. The Tomcat "deploy" ant task basically uploads the war file over an http session (into the Tomcat "manager" application), which redeploys it. Really cool...
As far as debugging, you can use the Eclipse JPDA debugger to remotely debug a z/OS application, including Tomcat. You need to start the JVM with the normal JPDA debugging switches that causes it to listen on some port. Then in Eclipse, you can create a Debugger launch configuration for a "Remote Java Application", specifying the hostname/ip address and port to connect to. z/OS Java works just like any remote JPDA target...
You might not need to resort to remote debugging...you should be getting a Java stack trace in the Tomcat log. Unless JITed, you should should be able to see source code line numbers of the methods in the stack below your NPE.
BTW: we haven't done any testing of Tomcat 5.5.x (only up through 5.0.28). Has anyone else used Tomcat 5.5 on z/OS?
-
Guest
debugging for newbies
As far as debugging, you can use the Eclipse JPDA debugger to remotely debug a z/OS application, including Tomcat. You need to start the JVM with the normal JPDA debugging switches that causes it to listen on some port. Then in Eclipse, you can create a Debugger launch configuration for a "Remote Java Application", specifying the hostname/ip address and port to connect to. z/OS Java works just like any remote JPDA target...
*****************************
The above sounds great, could you please give some details, we are all beginers on my team
What are the jpda debug switches ???
*********************
What happens if you are debugging a remote ebcdic version on an ascii debugger platform ???
***********************
*****************************
The above sounds great, could you please give some details, we are all beginers on my team
What are the jpda debug switches ???
*********************
What happens if you are debugging a remote ebcdic version on an ascii debugger platform ???
***********************
-
Guest
Hello,
from my last client site (who's running J2SDK 1.3 )
I've used Eclipse version 2.1.3 for debuging remote JZOS sessions
Regardless of the default file encoding (of Cp1047 or ISO8859-1), I found the following options to work
HSTDBG="8000"
IJO="-Xms21m -Xmx48m"
IJO="$IJO -Xdebug -Xnoagent "
IJO="$IJO -Xbootclasspath/p:$JAVA_HOME/lib/rt.jar:$JAVA_HOME/lib/tools.jar"
IJO="$IJO -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=$HSTDBG"
IJO="$IJO -Djava.compiler=NONE"
IJO="$IJO -Dfile.encoding=ISO8859-1"
export IBM_JAVA_OPTIONS="$IJO "
from my last client site (who's running J2SDK 1.3 )
I've used Eclipse version 2.1.3 for debuging remote JZOS sessions
Regardless of the default file encoding (of Cp1047 or ISO8859-1), I found the following options to work
HSTDBG="8000"
IJO="-Xms21m -Xmx48m"
IJO="$IJO -Xdebug -Xnoagent "
IJO="$IJO -Xbootclasspath/p:$JAVA_HOME/lib/rt.jar:$JAVA_HOME/lib/tools.jar"
IJO="$IJO -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=$HSTDBG"
IJO="$IJO -Djava.compiler=NONE"
IJO="$IJO -Dfile.encoding=ISO8859-1"
export IBM_JAVA_OPTIONS="$IJO "
Thank you very much for posting the example.
Responding to an earlier comment - there is no "EBCDIC" or "ASCII" version.... Java always run in Unicode. The -Dfile.encoding only controls the default conversion from internal Java characters to external bytes, and does not affect JPDA connections, which use unicode/utf.
Responding to an earlier comment - there is no "EBCDIC" or "ASCII" version.... Java always run in Unicode. The -Dfile.encoding only controls the default conversion from internal Java characters to external bytes, and does not affect JPDA connections, which use unicode/utf.