java.lang.NoSuchMethodError when starting debug session

[GoogleCodeExporter]

Google Chrome version: 2.0.172.39
SDK + Eclipse Debugger version(s):Eclipse Java EE IDE for Web Developers. 
Build id: 20090621-0832
OS + version: Windows XP Pro

What steps will reproduce the problem?

1. Start Chrome using a .bat file:
cd C:\Documents and Settings\34854Do\Local Settings\Application 
Data\Google\Chrome\Application
call chrome.exe --remote-shell-port=9222

2.Start an Eclipse debug session

What is the expected result?

A debug session starts

What happens instead?

An error dialog appears. The log is this:

java.lang.NoSuchMethodError: java.io.IOException: method 
<init>(Ljava/lang/String;Ljava/lang/Throwable;)V not found
at org.chromium.sdk.internal.BrowserImpl.connect(BrowserImpl.java:183)
at org.chromium.debug.ui.launcher.LaunchType.launch(LaunchType.java:69)
at 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurat
ion.java:853)
at 
org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfigurat
ion.java:703)
at 
org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.ja
va:866)
at 
org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1069)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Please provide any additional information below. If possible, attach a
(reduced) test-case.

Original issue reported on code.google.com by doug.sat...@ymail.com on 13 Aug 2009 at 9:34

[GoogleCodeExporter]

Doug,

Could you update the ChromeDevTools just in case, and retry? The latest 
ChromeDevTools build id is 0.1.0.200907271854, and nobody seems to have 
reported 
similar problems so far.

Apart from that, the Google Chrome version 2.0.172.39 is not compatible with 
the 
SDK/debugger. As per http://code.google.com/p/chromedevtools/, you must be 
running at 
least 3.0.189.0 for the SDK/debugger to function.

Original comment by apav...@chromium.org on 17 Aug 2009 at 12:57

[GoogleCodeExporter]

Hi Doug

Could you please specify version of your Java SDK.

Thanks,
Peter

Original comment by peter.ry...@gmail.com on 17 Aug 2009 at 3:49

[GoogleCodeExporter]

I was already using the latest ChromeDevTools, but I hadn't got the right 
version of Chrome so I installed the latest 3.x version. I haven't had much 
time to test it, but 
I no longer get an exception and I do have the project created when debugging, 
so I'm 
assuming its all OK. 

BTW - I'm a WTP committer at Eclipse.org, which is something I do in my spare 
time, 
having developed an XSLT launcher and debugger for Xalan, an XPath view etc. 
(see the 
new XML perspective in Eclipse JEE Galileo). Do you guys need an extra pair of 
hands 
on this project? I can maybe offer some help.

The JDK version was 1.6.0_13.

Thanks,

Doug

Original comment by doug.sat...@ymail.com on 18 Aug 2009 at 7:48

[GoogleCodeExporter]

Hi Doug,

An extra pair of hands would be great. We don't have committer policy 
established
yet, but it most likely is going to be Chromium-alike. (We are all chromium
committers). So we welcome patches and after some time take committers aboard.

What are you interested in doing? Here is what I can think of: we'd like to play
nicely with WTP. This includes re-using WTP viewers/editors for JavaScript and 
XML,
matching scripts fetched from the browser with the actual resources in the 
workspace,
setting breakpoints on these resources, editing them live, refreshing the 
browser and
seeing them being hit.

Thanks
Pavel

Original comment by pfeld...@chromium.org on 20 Aug 2009 at 6:12

[GoogleCodeExporter]

Hi Pavel - I can definitely help with WTP integration, as a large part of the 
XSL 
Tools project was to figure out how best to leverage the existing WTP code 
base. Do 
you have a page somewhere where you keep your planned items such as those you 
mentioned?

From my point of view, I would like to see scripts from the browser match to 
existing 
resources in the workspace. I don't know how much you've thought about this, 
but one 
potential way to do it would be to create files that are linked to resources in 
the 
filesystem. This works just like a symlink on Unix. For example, right-click on 
a 
project and select New -> File, and in that dialog expand the Advanced toggle. 
In 
there, you can specify the location of a resource anywhere in the filesystem, 
including another file in the workspace. There may be some work in 
synchronizing 
resource markers (such as breakpoints) between the real and symlinked file 
though.

This is a possible piece of functionality I could take a look at to start with?

Thanks,

Doug

Original comment by doug.sat...@ymail.com on 20 Aug 2009 at 8:39

[GoogleCodeExporter]

Hi Doug,

Sorry for not getting back to you for so long. This sounds great - we 
definitely want
to match to existing resources and WTP sounds like a project that we could 
leverage a
lot from.

We did not think much about it, so suggestions are welcome. It could be a 
lightweight
mapping where one could navigate from script list into the workspace and set
breakpoints there. So that no markers copying was necessary.

We were thinking of tracking features via issues tracker, it is just that it is 
not
yet populated. I think Peter and Alexander are working on it.

Thanks
Pavel

Original comment by pfeld...@chromium.org on 25 Aug 2009 at 2:34

[GoogleCodeExporter]

A bad Google Chrome version was used. Closing.
Doug, we'll contact you once we get to the new features. Meanwhile, you can 
examine the 
latest code changes in the trunk and consider plugging in the WTP JavaScript 
editor if 
one is available in the Eclipse platform instance.

Original comment by apav...@chromium.org on 11 Sep 2009 at 1:18

• Changed state: Invalid

[GoogleCodeExporter]

Ok - I've got the source and have had a look through. I've got a lot of other 
bits and 
pieces to finish up on other projects at the moment, but hopefully will find 
time to 
work on this soon as it looks like an interesting project.

Original comment by doug.sat...@ymail.com on 11 Sep 2009 at 1:33