JSwat 4.5 and Resin 4.0.10

[dj]

Anyone have problems getting JSwat 4.5 and Resin 4 working together?

I have been using JSwat with Resin 3 with no problems, just upgraded
to Resin 4 and now the it is not tripping on breakpoints.

[Nathan Fiedler]

This kind of issue has come up before and I don't know what the cause
could be. Try restarting JSwat, and if that doesn't work, exit JSwat,
delete or rename the ~/.jswat directory and try again.

Let me know if that helps or not.

n

[dj]

Nathan,

Thanks for your input.

I deleted the .jswat folder to no avail.

?

-dj

On Sep 2, 9:36 am, Nathan Fiedler <nathanfied...@gmail.com> wrote:
> This kind of issue has come up before and I don't know what the cause
> could be. Try restarting JSwat, and if that doesn't work, exit JSwat,
> delete or rename the ~/.jswat directory and try again.
>
> Let me know if that helps or not.
>
> n
>

[John Pritchard]

We've seen this occasionally, failure of breakpoints to bind. 

In the breakpoints panel there's a column named "resolved" that can be revealed from the table control within the top-right of the panel decorations.  This property will indicate the problem as an unresolved breakpoint.  With some experience you'll notice that breakpoints get resolved some time after the class is loaded.

Of course the java compiler needs optimization turned off and debugging turned on. 

If memory serves there may be another, exceedingly rare case when breakpoints fail to bind.  Somewhere in the neighborhood of the JVM.  Although off hand I can't recall / imagine what that is.

-john

--
You received this message because you are subscribed to the Google Groups "jswat-discuss" group.
To post to this group, send email to jswat-...@googlegroups.com.
To unsubscribe from this group, send email to jswat-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jswat-discuss?hl=en.

--
http://www.google.com/profiles/john.douglas.pritchard

[John Pritchard]

On Thu, Sep 2, 2010 at 5:14 PM, John Pritchard <j...@wtkx.org> wrote:

We've seen this occasionally, failure of breakpoints to bind. 

In the breakpoints panel there's a column named "resolved" that can be revealed from the table control within the top-right of the panel decorations.  This property will indicate the problem as an unresolved breakpoint.  With some experience you'll notice that breakpoints get resolved some time after the class is loaded.

Of course the java compiler needs optimization turned off and debugging turned on. 

If memory serves there may be another, exceedingly rare case when breakpoints fail to bind.  Somewhere in the neighborhood of the JVM.  Although off hand I can't recall / imagine what that is.

-john

 

Try running the debuggee (resin) using "java -Xint" (not "-Xmixed") for interpreted mode execution only when debugging

[dj]

John,

I turned on the "Resolved" column for breakpoints. All are unchecked,
except for "Uncaught Exceptions".

I added the -Xint option to the resin command line.

I double checked my ant build.xml file. I found that debugging is
turned on, but so were optimizations, which I have since turned off.
Still not stopping on breakpoints.

I tried the previous version of JSWAT, which I have used for over a
year, and it too is no longer stopping on breakpoints set.

I don't know if this matters, but I now find that JSWAT is no longer
remembering to re-open files from session to session. For example, I
open fileA, exit JSWAT, launch JSWAT.exe, and the workspace is empty,
fileA is not automatically reloaded. I do see however, that the
breakpoints are still set.

I have also recently transitioned from Java 1.5 to 1.6

Thanks for your help so far.

-dj

[John Pritchard]

I turned on the "Resolved" column for breakpoints.  All are unchecked,
except for "Uncaught Exceptions".

I added the -Xint option to the resin command line.

I double checked my ant build.xml file. I found that debugging is
turned on, but so were optimizations, which I have since turned off.
Still not stopping on breakpoints.

I tried the previous version of JSWAT, which I have used for over a
year, and it too is no longer stopping on breakpoints set.

This confirms a classfile/jvm problem

Might want to be sure you have a clean build, that all classfiles in the packages you're setting breakpoints in have been recompiled without opt and with debugging.

 

I don't know if this matters, but I now find that JSWAT is no longer
remembering to re-open files from session to session.  For example, I
open fileA, exit JSWAT, launch JSWAT.exe, and the workspace is empty,
fileA is not automatically reloaded.  I do see however, that the
breakpoints are still set.

I have also recently transitioned from Java 1.5 to 1.6

The Jswat/netbeans session is independent, and will probably resolve itself.

Cheers,
John

[John Pritchard]

Might want to be sure you have a clean build, that all classfiles in the packages you're setting breakpoints in have been recompiled without opt and with debugging.

ps. (had intended to explain) delete all the classfiles in your project and rebuild

[dj]

John,

>ps. (had intended to explain) delete all the classfiles in your project and

Yes, I have repeatedly done that.

Deleted the JAVA_HOME/.jswat folder
added -Xint to the resin server command line.
Showing the Resolved column for breakpoints, though they are not
resolving.

JSWAT is now remembering to re-open files. Yeah!

Not breaking on BPs.

[John Pritchard]

Well, can review.

Both the debugger and debuggee are on the identical JVM (software/version).

The JIT is off on the debuggee, which is running in interpreted mode.

Debugging information is compiled into target binaries.

We know it's not a more basic problem, we can see threads for example in the debuggee.

I recall some THREADS=native kind of env.var thing but not whether it's really related.  Some problem with green threads in the runtime.

Might check in that direction?

[John Pritchard]

I recall some THREADS=native kind of env.var thing but not whether it's really related.  Some problem with green threads in the runtime.

Might check in that direction?

ps.  http://www.google.com/search?q=THREADS_FLAG%3Dnative

[dj]

After I "Attach", in the Threads pane I see:
System
main
reference handler
Finalizer
Attach Listener

[dj]

[dj]

>> Both the debugger and debuggee are on the identical JVM (software/version).

Well let's look at that a bit.

JSWAT 4.5
In the jswat.conf file we have
netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_21"



RESIN 4.0.10

I start with a batch file which looks like this:
set java_home=C:\Program Files\Java\jdk1.6.0_21
set resin_home=C:\resin-pro-4.0.10

resin.exe gui -classpath %classpath% -J-
Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Xms151m -
Xmx451m -verbose -Xdebug -Xint -
Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000


Project:
I also explicitly set the java_home, as above.
While I have recompiled my code, there are third party jars and so
forth that are of other version, even back to 1.4.2.

I don't know if any of that helps, but since we were reviewing that
situation so far...

[dj]

All,

I have solved the problem. JSWAT is now able to resolve and hit
breakpoints.

In converting from Resin 3 to 4, they have changed the option for the
configuring interaction with a debugger.

Removing this option from the command line:
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000

And simplifying the command line to:

resin.exe gui -debug-port 5000

Solved the problem.

Thank you to all who helped.

-dj

[John Pritchard]

On Tue, Sep 7, 2010 at 2:41 PM, dj <defen...@yahoo.com> wrote:

All,

I have solved the problem.  JSWAT is now able to resolve and hit
breakpoints.

In converting from Resin 3 to 4, they have changed the option for the
configuring interaction with a debugger.

Removing this option from the command line:
    -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000

And simplifying the command line to:

     resin.exe   gui  -debug-port 5000

Solved the problem.

Thank you to all who helped.

-dj

Cool beans :)
 

[John Pritchard]

On Fri, Sep 3, 2010 at 7:24 PM, John Pritchard <synt...@gmail.com> wrote:

On Fri, Sep 3, 2010 at 5:37 PM, dj <defen...@yahoo.com> wrote:

>> Both the debugger and debuggee are on the identical JVM (software/version).

Well let's look at that a bit.

JSWAT 4.5
   In the jswat.conf file we have
   netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_21"



RESIN 4.0.10

I start with a batch file which looks like this:
   set java_home=C:\Program Files\Java\jdk1.6.0_21
   set resin_home=C:\resin-pro-4.0.10

   resin.exe   gui -classpath %classpath% -J-
Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Xms151m -
Xmx451m -verbose -Xdebug -Xint -
Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000


Project:
I also explicitly set the java_home, as above.

 

While I have recompiled my code, there are third party jars and so
forth that are of other version, even back to 1.4.2.

We only need to look into the binaries for packages for breakpoints.  Otherwise of course if the JVM successfully loads the class, then it's good.

So the debuggee code is executing, just not stopping at breakpoints.

I see the jvm launcher "resin.exe".  Perhaps this has a bug?

Better check on that, since you've said that you haven't had breakpoints since using this version of this launcher.

ps. Whether or not it's known to debug with eclipse (for example) would be equivalent (jdwp)

[John Pritchard]

On Fri, Sep 3, 2010 at 5:37 PM, dj <defen...@yahoo.com> wrote:

>> Both the debugger and debuggee are on the identical JVM (software/version).

Well let's look at that a bit.

JSWAT 4.5
   In the jswat.conf file we have
   netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_21"



RESIN 4.0.10

I start with a batch file which looks like this:
   set java_home=C:\Program Files\Java\jdk1.6.0_21
   set resin_home=C:\resin-pro-4.0.10

   resin.exe   gui -classpath %classpath% -J-
Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Xms151m -
Xmx451m -verbose -Xdebug -Xint -
Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000


Project:
I also explicitly set the java_home, as above.

 

While I have recompiled my code, there are third party jars and so
forth that are of other version, even back to 1.4.2.