 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / September 2005Using JDB with JPDA (to launch my own LaunchingConnector)
Ok, I am now officially confused... I read http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda_spis.html, and deployed my connector (for now, just to see that it works, Sun's sample one) as they specified. I then tried to do connect to it with JPDA (as specified in http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#JDB). I tried using -connect option, but it said invalid option: -connect=org.hrum.dbdb.DbdbLaunchingConnector (and gave me a usage screen which included -connect). I then tried to just do jdb -listconnectors, and, I got java.lang.NoClassDefFoundError: com/sun/jdi/connect/LaunchingConnector and then a list of connectors (which didn't include mine). Now, when I reread "Connecting with JDB" paragraph, the phrase "The example implementation of JDB provided with the JPDA" caught my eye. I then thought that I need another JDB, the reference one that comes with JPDA download, not the one included with JDK. But then, http://java.sun.com/products/jpda/download.html claims JPDA is already included with the download. So what's up? >I read http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda_spis.html, >and >deployed my connector (for now, just to see that it works, >Sun's sample one) as they specified. Presumably, there is some registration process. You must add your connector plugin to some configuration file, or call some registration API, the way JCE works.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. But even so (see other reply), why do I get this: > I then tried to just do jdb -listconnectors, and, > I got > java.lang.NoClassDefFoundError: com/sun/jdi/connect/LaunchingConnector >> I then tried to just do jdb -listconnectors, and, >> I got >> java.lang.NoClassDefFoundError: com/sun/jdi/connect/LaunchingConnector For the generic answer to that question see http://mindprod.com/jgloss/runerrormessages.html#NOCLASSDEFFOUNDERROR This is the mother of all error messages, the most difficult to track down. Presuming that LaunchingConnector is the name of your custom implementation: I would guess that you must have created such a beast oddly in package com.sun.jdi.connect I would further guess that in addition to the manifest thing, you must put this class in a jar on the classpath under the name com/sun/jdi/connect/LaunchingConnector.class If Sun using some special class loader, it may need to live in some special place. If you have not already followed the suggested instructions, I suggest trying them rather than wasting time with arguments why you should not have to. The Java libraries were created by fallible humans. They don't have to be logical. When a program is not working, WHY it is not working is much more baffling than later after you find out what works. It is a fun game to try to analyze bizarre behaviours, but if you have some plausible things you can change to make it work, it is almost invariably faster just to try them, then after you are done, indulge in the luxury of figuring it out. From the end perspective, the reasons for the strange behaviour are often blindingly obvious where they were deep mysteries moments before. I tell you this as one addicted to figuring out why programs behave strangely even when it there in no practical need. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >> java.lang.NoClassDefFoundError: >>com/sun/jdi/connect/LaunchingConnector > Presuming that LaunchingConnector is the name of your custom > implementation: No, it's not. But in tools.jar, there exists a com.sun.jdi.connect.LaunchingConnector class. My class is correctly placed in the JAR (I checked). And that jar, per their instructions, I put in JAVA_HOME\jre\lib\ext (I have since tried other locations as well). I'm trying to say that I have followed instructions to the letter. You say: > The Java libraries were created by fallible > humans. They don't have to be logical. I agree. My question basically relates to the fact that so is the documentation -- it may be wrong. >No, it's not. But in tools.jar, there exists a >com.sun.jdi.connect.LaunchingConnector class. I have never used these specific classes, so please bear with me. The com.sun classes are harder to deal with than ones Sun fully exposes.. What is YOUR custom class called, including package? What interface does it implement, including package? What does the java.classpath system property say. see http://mindprod.com/jgloss/properties.html Insert code to detect it as close as you can to the failure point. This problem is likely complicated by unknown custom classloaders. When you get the NoClassDefFoundError, please show the complete stack trace. Go to http://mindprod.com/jgloss/systemsinternals.html entry and go get a copy of the free filemon utility. It will let you know where Java is looking for things. You can also turn on the java.exe -verbose option to give you more of a picture what is happening. This class of problem is tough to track. It doubly so trying to solve the problem remotely without seeing the full source. Any chance of an SSCCE? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >I then tried to do connect to it with JPDA (as specified in >http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#JDB). maybe you also have to do this: Suppose we wish to deploy a launching connector named SimpleLaunchingConnector. In order to deploy this we create a file META-INF/services/com.sun.jdi.connect.Connector similar to the following: # Our very simple launching connector SimpleLaunchingConnector This service configuration file is then packaged into a jar file along with the classes that comprise the implementation of the Connector: jar cf SimpleLaunchingConnector.jar \ META-INF/services/com.sun.jdi.connect.Connector \ SimpleLaunchingConnector.class The jar file is then copied into a location that is visible to the system class loader. In the Sun implementation the jar file might be copied into the extensions directory as follows: cp SimpleLaunchingConnector.jar $JAVA_HOME/lib/ext Once deployed the Connector will be located by the debugger when the debugger is restarted. That is, SimpleLaunchingConnector will be included in the list of Connectors returned by VirtualMachineManager's allConnectors() method. In addition, as this is a launching connector, it will also appear on the list of launching connectors returned by the launchingConnectors() method. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > The jar file is then copied into a location that is visible to the > system class loader. In the Sun implementation the jar file might be > copied into the extensions directory as follows: Yes, I did that... >I read http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda_spis.html, >and >deployed my connector (for now, just to see that it works, >Sun's sample one) as they specified. I read these instructions and notice they are misleading because they presume you would write your code without a package! # Our very simple launching connector SimpleLaunchingConnector This service configuration file is then packaged into a jar file along with the classes that comprise the implementation of the Connector: jar cf SimpleLaunchingConnector.jar \ META-INF/services/com.sun.jdi.connect.Connector \ SimpleLaunchingConnector.class The jar file is then copied into a location that is visible to the system class loader. In the Sun implementation the jar file might be copied into the extensions directory as follows: cp SimpleLaunchingConnector.jar $JAVA_HOME/lib/ext ----------------------------------------------------------------- Presuming a package, the instructions might look more like this: the file you create looks like this. make sure it has a terminal linefeed. # Our very simple launching connector com.mindprod.launch.SimpleLaunchingConnector This service configuration file is then packaged into a jar file along with the classes that comprise the implementation of the Connector: jar cf SimpleLaunchingConnector.jar \ META-INF/services/com.sun.jdi.connect.Connector \ com/mindprod/launch/SimpleLaunchingConnector.class Verify the jar members are correctly named with WINZIP or other zip utility. The jar file is then copied into a location that is visible to the system class loader. In the Sun implementation the jar file might be copied into the extensions directory as follows: cp SimpleLaunchingConnector.jar \ "e:\program files\java\jdk1.5.0_05\lib\ext" SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >jar cf SimpleLaunchingConnector.jar \ > META-INF/services/com.sun.jdi.connect.Connector \ > SimpleLaunchingConnector.class once you have created your jar, please do a jar.exe -t to dump out a listing of its members. That might give a clue. Everything is case sensitive. also dump out your .Connector file. View it with a hex viewer to make sure it end with a line terminator. Manifests are funny that way. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. Ok, I think I have it now: 1. I had to put tools.jar from the JRE's home (as different from JAVA_HOME, which, apparently, is assumed to be JRE's home -- to wit, if you have JDK installed, it's, e.g., D:\jdk1.5.0\jre rather than D:\jdk1.5.0). In other words, dropping the tools.jar into the jre/lib/ext folder in addition to it's righteous place in <JDK_INSTALL_DIR>lib did the trick of getting rid of that pesky ClassDefFoundError. . 2. You should properly override name() of the Connector you're implementing correctly for diagnostic (so that you're not confused by the output of jdb -listconnectors) but that's a minor thing... >1. I had to put tools.jar from the JRE's home (as different from >JAVA_HOME, [quoted text clipped - 6 lines] ><JDK_INSTALL_DIR>lib did the trick of getting rid of that pesky >ClassDefFoundError. . That is taking the mountain to Mohammed. You probably should have just used the java.exe in the jdk than the jre. See http://mindprod.com/javaexe.html#COMMANDLINE and look at -server. It has a similar problem. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > You probably should have > just used the java.exe in the jdk than the jre. A, but you're forgetting -- I was trying ot use JDB, not java.exe. I figured this thing out. 1. You had to put tools.jar from the JRE's home (as different from JAVA_HOME, which, apparently, is assumed to be JRE's home -- to wit, if you have JDK installed, it's, e.g., D:\jdk1.5.0\jre rather than D:\jdk1.5.0). In other words, dropping the tools.jar into the jre/lib/ext folder in addition to it's righteous place in <JDK_INSTALL_DIR>lib did the trick of getting rid of that pesky ClassDefFoundError. . 2. You should override name() of the Connector you're implementing correctly for diagnostic (so that you're not confused by the output of jdb -listconnectors) but that's a minor thing... Thanks to all who tried to help... Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.