Attach Java debugger to inline command

I am trying to attach a java debugger to an inline command so I can debug via eclipse remote debugging.

I was trying something like:

Find more posts tagged with

Comments

Adam Stoller

I am trying to attach a java debugger to an inline command so I can debug via eclipse remote debugging.

I was trying something like:
<inline command="/SAN01/apps/Interwoven/TeamSite/tools/java/bin/java
-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n
...

but this doesn't seem to work...

any suggestions or pointers?

Attempting to fix the post - please try to remember to Preview your posts before you Submit them to the forums.

As for the question - I don't know the answer, I've never tried to attach the eclipse to such a process

Rick Poulin

Can't think of any reason why this wouldn't be possible. Can you expand on "doesn't work"?
* Does the form render or do you get an error?
* Assuming it renders, does your call return the data you'd expect, or no data at all?
* Does the data come across any better if you remove the debugging flags from the same command?
* If you copy that exact command and run it from the shell, does it trigger your debugger?
Basically, I'd debug this exactly as I would any other inline command, and then narrow it down to a problem with the debug flags specifically. Also, note that you're attaching the debugger to a standalone Java app that returns the inline content. You're NOT going to be able to get any information at all from the calling process, since it's a distinct process entirely. All you'll get by trying it that way versus in a shell directly, is you'll be able to see the environment passed to the call -- and that's something you could debug much more easily if you write a quick perl script that prints the $ENV to a text file.

mohanss

Can't think of any reason why this wouldn't be possible. Can you expand on "doesn't work"?
* Does the form render or do you get an error?
* Assuming it renders, does your call return the data you'd expect, or no data at all?
* Does the data come across any better if you remove the debugging flags from the same command?
* If you copy that exact command and run it from the shell, does it trigger your debugger?
Basically, I'd debug this exactly as I would any other inline command, and then narrow it down to a problem with the debug flags specifically. Also, note that you're attaching the debugger to a standalone Java app that returns the inline content. You're NOT going to be able to get any information at all from the calling process, since it's a distinct process entirely. All you'll get by trying it that way versus in a shell directly, is you'll be able to see the environment passed to the call -- and that's something you could debug much more easily if you write a quick perl script that prints the $ENV to a text file.

The form does not render when using the following line:

The error is:
Root cause:
ERROR: transport error 202: socket creation failed: Provider initialization failed (check %SystemRoot%) ["transport.c",L41] ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L500] JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized

- The form renders correctly when the debug command is removed.
- The command used works when triggered from the shell and debugging is possible. This works for now so i am going to use it...

- I was successful in attaching a debugger to the JVM that runs the servletd(Tomcat) service, so most of the custom code can be remotely debugged. The difference here is a new JVM instance is created to execute the inline command.
For now I can run the code via the shell when debugging is required. It seems to work properly. Thanks for the suggestion.

If there is a way to execute the inline code in an existing JVM (Servletd/Tomcat) instance then that would ideal since a debugger is already attached to it...

thanks,

Rick Poulin

If there is a way to execute the inline code in an existing JVM (Servletd/Tomcat) instance then that would ideal since a debugger is already attached to it...

If you're on 6.7 or later, you can do that by using Datasources instead of an actual command line. The documentation is (strangely enough) in the WFM pdf.