|
Francess, Your instructions worked. If anyone else is interested, here is what worked. I created a new directory called classes in Tomcat's root (this is where Tomcat /lib is). Next I compiled to that directory with both .class and .java. I then deleted the original .jar. Next, I changed my Tomcat startup script to specify -Djava.compiler=NONE and also added the /classes directory to the startup CLASSPATH. Once Tomcat started, I ran the strdbgsvr command, located the server job (this one was qp0zspwt), and started the distributed debugger. I specified my qp0zspwt job and entered the class that I wanted to debug. Next, I went to the offending web page and hit shift-F5. I am still trying to figure out the debugger, but this is miles ahead of logging statements. That's about it, thanks for your help. I did find that I have no help text for the distributed debugger on this system (I installed it via WDT400). I did have help text on my other system where it was installed as part WS Studio Advanced. Thanks, David Morris >>> francess@us.ibm.com 05/04/01 04:34 AM >>> Hopefully some of this information will help: 1). You don't need to do the javac -g on the 400. It is fine to use the debuggable code that comes from VAJ, or if the javac -g was done on your PC. 2). You do need to have the source files (*.java) be in a directory (i.e. not in the jar file with the classes). The system debugger and the distributed debugger both have this requirement. The easiest way is to have the source be in the same directory as the jar file, but you can also use the DEBUGSOURCEPATH environment variable to specify the location of the source if it is not. 3). Neither the system debugger nor the distributed debugger will work if the class is loaded b a custom classloader (you mention 'Tomcat's classloader' below). The class must be loaded by the system class loader (a.k.a JVM class loader). Generally customer class loader's always defer to the system class loader to load a class if possible, so if Tomcat has a mechanism for specifying a classpath that is passed into the JVM (e.g. java -classpath ...), you should use that. That does mean you will have to stop and restart Tomcat whenever you introduce a debuggable class. If Tomcat does not have a mechanism for specifying -classpath ... classes, you could try putting the classes in /QIBM/ProdData/Java400. You would need to extract the classes from the jar file and make sure they are in the appropriate package scoped directory structure under /QIBM/ProdData/jJava400. This path is always on the classpath for the JVM. 4). Neither the system debugger nor the distributed debugger work if the JITC (Just-in-time compiler) is being used. In v4r5 and later I believe this is the default. To disble the JITC, you need to specify JVM system property java.compiler=NONE. If Tomcat does not have a way for you to pass in -Djava.compiler=NONE when starting the JVM (e.g. java -Djava.compiler=NONE), you can specify this in the SystemDefault.properties file at various levels depending on your need and who you want to impact. 5). You do not need to use RUNJVA to start Tomcat in order to debug using the AS/400 System Debugger. Item 6 and 8 below contain links to more detailed documentation on this, but basically you use STRSRVJOB and STRDBG to accomplish debugging of a job that is already running. 6). This link might help: http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/java/rzaha/debserv.htm It is a short list of the steps to debug a servlet on the 400. You can get to it by going to the v4r5 Information Center then expanding Programming->Java->AS/400 Development Kit for Java->Debugging->Debug servlets 7). The IBM Distributed Debugger does contain information on debuggingon the AS/400 in its help files. 8). Lastly the WebSphere documentation contains information on using both the system debugger and the IBM Distributed Debugger to debug servlets, JSPs and EJBs. You would need to extrapolate to Tomcat on some of the information, but I think the detailed info on the STRSRVJOB and STRDBG commands will help you, and the information pertainining to Using the IBM Distributed Debugger in standalone mode will help. The starting point for this documentation is at http://www-1.ibm.com/servers/eserver/iseries/software/websphere/wsappserver/docs/as400v35std/docs/trb.html The two topics you would be interested in are 'Using the IBM DIstributed Debugger without Object Level Trace' and 'Using the AS/400 System Debugger'. Frances Stewart WebSphere Application Server for iSeries 400 IBM Rochester "David Morris" <dmorris@plumcreek.com>@midrange.com on 05/03/2001 05:21:17 PM Please respond to JAVA400-L@midrange.com Sent by: owner-java400-l@midrange.com To: <JAVA400-L@midrange.com> cc: Subject: Debugging Servlets Group, I have been working with some large Jar files trying to work out some bugs. My debug process is to add logging statements where necessary and then republish the results. This code is only having a problem running on my iSeries and not on any other platform that I have deployed it to. I am using the Enterprise version of VA/Java and its debugger works great when running on my PC. I tried the distributed debugger and can't seem to get it to work against my deployed Jar files. I compile and deploy with debugging enabled. I am using Tomcat so it is not too much bother to run this interactively. I have not figured out how to debug code in a Jar file and removing a single class causes a problem with Tomcat's class loader (it always picks up the Jar version). I have a couple of ideas. First deploy as java files and then compile on the AS/400 and run javac -g. I am not sure how I start debugging unles I use runjva against tomcat start. Is there a way to pick up a class other than the initial class? Also how would I compile my 400 classes with javac (I suspect a simple qshell script, but an example would help). The next idea is to figure out the distributed debugger, which I think is hindered by the same problems I am seeing with the interactive debugger. I appreciate any input or ideas. David Morris +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.