At 04:52 PM 8/14/00 -0500, you wrote:
>Hi Paul:
>
> I've gotten the jde-bug product installed and somewhat functional on our
>Solaris 7 dev box. I'm using Xemacs 20.4 as the client engine to run the
>jde-bug tool. I'm launching my server Java process that I want to debug
>using:
>
>JavaServer -C dom=eBase -i 6 -i 81 -u devel-srv5 -U
>/export/home/wleadm/wbase/wle/Logs/ULOGS/ULOG -m 0 -A -- -Xdebug -Xnoagent
>-Xbootclasspath:/usr/Solaris_JDK_1.2.2_05a/lib/tools.jar:/usr/Solaris_JDK_1.
>2.2_05a/jre/lib/rt.jar
>-Xrunjdwp:transport=dt_socket,address=9200,server=n,suspend=y
>WLELoginProxyImpl.jar wleport none Acol LoginProxy none
>
>
>I receive the following output in the WebLogic Enterprise 5.1 (Tuxedo on
>CORBA steriods)
>log:
>
>183327.devel-srv5!JavaServer.2693: 08-14-2000: TUXEDO Version 6.5forWLE5.1
>183327.devel-srv5!JavaServer.2693: LIBTUX_CAT:1539: ERROR: Error getting
>Group Environment filename
>183327.devel-srv5!JavaServer.2693: LIBTUX_CAT:1296: WARN: Cannot retrieve
>own server group table entry
>183327.devel-srv5!JavaServer.2693: LIBTUX_CAT:262: INFO: Standard main
>starting
>183327.devel-srv5!JavaServer.2693: IJINFRA_CAT:2: INFO: Starting JVM
>183327.devel-srv5!JavaServer.2693: IJINFRA_CAT:318: INFO: Static jar
>management in effect
>
>The server has not at this point fully come up yet as it should be suspended
>(suspend=y) awaiting
>for the client jde-bug to attach via port=9200...correct?
>
>I then go to Xemacs, (note it was already listening for the incoming
>connection on this port).
>but the server never fully comes up? Why not? If I use server=y, suspend=n
>as options
>to starting the JavaServer, the server will fully startup. It spews a
>message into the WebLogic
>log file indicating that there is an -Xdebug Agent Password in effect of
>some 6 digit string. How
>is this used with jde-bug (if at all)? This may be what's causing things to
>get hung up.
>
>Thx for any insight.
>Regards,
>Wendell
>
I don't know anything about WebLogic Enterprise and you are not very clear
on exactly what you think you are doing and what you have actually done so
I really can't be of much help except to point out the following.
JDEbug supports two ways of connecting to an application that it does not
itself launch: attach mode and listen mode. Each of these modes can be
thought of as an interaction between a client and a server. In attach mode,
the application vm is the server and JDEbug is the client. In listen mode,
JDEbug is the server and the application vm is the client. You use the
-Xrunjdwp server argument to specify whether the application vm starts up
as a server (server=yes, attach mode) or as a client (server=no, listen
mode). You can use the -Xrunjdwp suspend argument to specify whether the vm
should suspend the application when it connects to the JDEbug client
(suspend=yes). In listen mode, the first thing an application vm does on
start up is to try to connect to a debuggee client vm.The suspend argument
determines, I believe, whether the vm then immediately invokes the
application's vm argument or waits for a resume message from JDEbug.
I notice that you specify listen-mode -Xrunjdwp arguments to some command
that apparently launches a vm of some kind. It is not apparent to me how
many vm's are involved in startup of the server and to which vm's if any
the arguments are specified. Trying to attach to an embedded vm is always
problematic as it is never clear whether the -Xrunjdwp arguments get
applied. For example, the company I work for has a product consisting of an
executable that launches a vm. It allows you to specify a -jdb debug
command line argument that causes it to launch the vm with the arguments
required to accept an attachment from Sun's old jdb debugger. You can also
specify other vm arguments via a file that the executable reads at startup.
However, specifying -Xrunjdwp arguments does no good because they conflict
with the jdb command line arguments. The message that you are getting is
typical of a vm that is started in serve jdb client mode. The moral is that
you may need to find out what is going on under the hood of the executable
that launches the server you want to debug.
- Paul
>
>Attachment Converted: "g:\eudora\attach\Mackenzie, Wendell D..vcf"
>
