Using JDB with JPDA (to launch my own LaunchingConnector)

[deb...@gmail.com]

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?

[Roedy Green]

On 24 Sep 2005 20:24:27 -0700, deb...@gmail.com wrote or quoted :

>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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On 24 Sep 2005 20:24:27 -0700, deb...@gmail.com wrote or quoted :

>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.

[deb...@gmail.com]

> 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...

[deb...@gmail.com]

But even so (see other reply), why do I get this:

[Roedy Green]

On 25 Sep 2005 11:15:29 -0700, deb...@gmail.com wrote or quoted :

>> 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.

[deb...@gmail.com]

>> 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.

[Roedy Green]

On 26 Sep 2005 14:10:36 -0700, deb...@gmail.com wrote or quoted :

>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?

[Roedy Green]

On 24 Sep 2005 20:24:27 -0700, deb...@gmail.com wrote or quoted :

>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"

[Roedy Green]

On Mon, 26 Sep 2005 23:13:51 GMT, Roedy Green
<loo...@mindprod.com.invalid> wrote or quoted :

>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.

[deb...@gmail.com]

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...

[deb...@gmail.com]

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...

[Roedy Green]

On 27 Sep 2005 16:36:23 -0700, deb...@gmail.com wrote or quoted :

>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. .

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.

[deb...@gmail.com]

> 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.