zgauthier8286 / chromedevtools

Automatically exported from code.google.com/p/chromedevtools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

ReverseSourceLookup.wrapNonVirtualContainer is out of sync with SourceNameMapperContainer.findSourceElements when using a WorkspaceSourceContainer #92

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
SDK/Debugger version: 0.3.9 (current checked trunk out)
Eclipse version: 3.7.2
Google Chrome/V8 Embedder + version: N/A
[For WebKit (WIP) protocol] Backend version: N/A
OS + version:

What steps will reproduce the problem?
I have a source mapper configured with Workspace scope.
because my urls are like this:

http://localhost:8080/test/test.js
http://localhost:8080/test2/test.js

the prefix is http://localhost:8080 (i can't use the extra slash because then 
setting breakpoints wants to send it to: http://localhost:8080//test/test.js so 
with an extra /)

the ReverseSourceLookup works perfect because /test/test.js on the workspace:

if (container instanceof WorkspaceSourceContainer) {
      return new ContainerWrapper() {
        @Override
        public String lookup(IFile resource) {
          return lookupInResourceContainer(resource, ResourcesPlugin.getWorkspace().getRoot());
        }
      };

when using that code so the resource == /test/test.js and the workspace root is 
really the workspace root then it finds my file correctly

But the implementation of WorkspaceSourceContainer is really that it 
genererates ProjectSourceContainers and ask the project source container on its 
name so it expects "test.js" 
I think this is kind of a bug in eclipse. because thats not what i ask for.. I 
don't say that i want to search relative to a project, i want to search 
relative to the workspace root...

But the problem is that the reverse lookup does it how i expect it to behave 
but the other way around (when the breakpoint is hit) then it can't find it.

i patched it in SourceNameMapperContainer.findSourceElements

i added this part inside that method:

 String shortName = name.substring(prefix.length());
    if (targetContainer instanceof WorkspaceSourceContainer) {
         IFile file = ResourcesPlugin.getWorkspace().getRoot().getFile(Path.fromOSString(shortName));
         if (file != null && file.exists()) return new Object[] {file};
    }

then it behaves the same and the source is found.

Original issue reported on code.google.com by jcompag...@servoy.com on 12 Sep 2013 at 3:21

GoogleCodeExporter commented 8 years ago
to make it a bit more clear: test/test.js  that first test is really a project 
and that test.js is a file inside that project. This is because what is running 
in the browser is really multi project for us. So i make sure that the urls are 
also really constructed like this so that we can debug it nicely.

Original comment by jcompag...@servoy.com on 12 Sep 2013 at 3:25

GoogleCodeExporter commented 8 years ago
The problem is that ReverseSourceLookup on a WorkspaceSourceContainer can also 
go wrong just fine because that code (and my patch) expects that the project is 
really in the workspace root. This doesn't have to be the case.
the project itself can be in a completely different location then the workspace 
root.

So the right implementation should be to first get the project by name (the 
first name in the resource path) and then ask the project for the resources.

Original comment by jcompag...@servoy.com on 12 Sep 2013 at 3:29