At 08:07 AM 8/15/00 -0500, you wrote:
>Hi Paul:
>
>Sorry about the vagueness of the problem. BEA WebLogic Enterprise is
>BEA Systems CORBA Object Transaction Monitor. JavaServer is a "C" wrapper
>that launches the jvm. WLE (WebLogic Enterprise) uses Tuxedo's
>infrastructure
>for messaging between clients and servers. This is what the JavaServer
>wrapper is doing. When it receives incoming object requests, it hands off
>these messages to the appropriate method in the server that is least busy.
>
>I added the -Djava.compiler=NONE and retried this morning. No change.
>I also added the -Xnoagent to see if the problem is password related.
>I think this is where things are going amuck. My JavaServer when
>launched manually (as described below), gets to the point where is
>is loading the .jar file for the server and then just hangs. If I
>terminate the script that launches it, the WLE Log file indicates
>that there was No agent password specified so I presume it's looking
>for one. I guess this is the function of -Xnoagent.
No!
This argument tells the application vm that it should be prepared to
connect to a debugger that conforms to the new JPDA (e.g., JDEbug) rather
than to a debugger that conforms to the Java debugger architecture that
preceded JPDA (e.g., oldjdb).
You should read the JPDA documentation included with the JDK. You should
also read the JDEbug user's guide.
>How does the
>Xemacs jde-bug debugger pass the password to the server side JavaServer
>jvm environment? Can this be done?
>
The password is a concept that belongs to the old jdb style debugger
architecture. It is outmoded in the new JPDA to which JDEbug conforms. If
the application vm is asking for a password, it means that is is probably
operating in the old debug mode and therefore will not be able to connect
to JDEbug.
JPDA-based debuggers use either a socket address or a shared memory channel
name (on Windows in shmem mode only, see the JDEbug doc for more info) to
determine which socket or which shmem channel to use for a debugger-app
connection.
The application vm gets the socket or shmem address from the
-Xjdwp,address=NNNN command-line argument where NNNN can be any socket
address available on the system that hosts the vm (or an arbitrary string
in the case of shmem connections on Windows). You must also specify NNNN as
the address when issuing the attach or listen command in JDEbug. This is
all spelled out in the JDEbug documentation.
- Paul
>Thx for your help,
>Wendell
>
>-----Original Message-----
>From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
>Sent: Monday, August 14, 2000 9:57 PM
>To: Mackenzie, Wendell D.
>Cc: [EMAIL PROTECTED]
>Subject: Re: jde-bug
>
>
>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"
>>
