Bugzilla – Full Text Bug Listing
| Summary: | Can't find source code when debugging WTP web project using "Allow output folders" and Tomcat 6 server adapter | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Mike Wilson <mikewse> | ||||||
| Component: | jst.server | Assignee: | Larry Isaacs <larryisaacs> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Angel Vera <arvera> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | arvera, ccc, david_williams, fbricon, stryker, thatnitind | ||||||
| Version: | 3.2 | Flags: | arvera:
review+
|
||||||
| Target Milestone: | 3.2.3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| See Also: | https://git.eclipse.org/r/109017 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 181994 [details]
example projects
Interesting. Assigning to Chuck for initial investigation. Quoting Snjezana Peco (via Max Andersen in m2eclipse-user ML) : "The problem is related to the Tomcat adapter (Tomcat's sourcePathComputers ext.point isn't implemented correctly). It can't be reproduced using either WTP JBoss AS adapter, JBT JBoss AS adapter or using any adapter that uses the generic sourcePathComputers ext. point." Adding Larry to the cc list, in case this really is a Tomcat-only problem. Great finding Snjezana/Max/Fred! I can confirm that the GlassFish 3 adapter is also showing the source code correctly (although this adapter seems to have its flaws in other respects). I'm a bit swamped at the moment. I'll try to take a look at this this weekend. I had hoped to find time to do some additional research, but what I found this past weekend shows the problem is local to the Tomcat plug-in. However, what "goes wrong" is in JDT, so I'm not sure if JDT has a bug or the Tomcat plug-in needs to do something different. Hence, more research is needed. Until then, this bug belongs to the Tomcat plug-in. The TomcatSourcePathComputerDelegate is using JavaRuntime methods computeUnresolvedSourceLookupPath(), resolveSourceLookupPath(), and getSourceContainers(). When the utility project is using just the default output folder, the utility project appears in the resolved classpath as a "project" entry. However, when it uses any non-default output folder, then that "project" entry disappears and is replaces with a "binary library folder" entry for each output folder used in the utility project. The source folders these "binary library" entries don't get included in the list. I still need to figure out where JDT and/or Tomcat should be doing something differently. Created attachment 186410 [details]
Patch to include dependent project directly in the resolved classpath
Since dependent projects with non-default output folders may not resolve their source folders correctly when indirectly referenced, add those projects directly to the classpath to be resolved.
Angel, Please review for inclusion in WTP 3.2.3. Looks good to me. Fix released to HEAD and 3.2 maintenance and appears in current WTP 3.3 and 3.2.3 builds. New Gerrit change created: https://git.eclipse.org/r/109017 |
Build Identifier: 20100917-0705 When a Dynamic Web Project's Deployment Assembly includes other workspace projects these will not be available for debugging if they use the "Allow output folders for source folders" Java Build Path setting. This is f ex a problem with Maven projects. Reproducible: Always Steps to Reproduce: Start with a vanilla Java EE Eclipse 3.6.1. Unpack the the supplied zip-file and add the contained projects to the workspace. The projects are: dynwebapp (a standard Dynamic Web project) webmodule (a standard Java project) The dynwebapp project refers to webmodule through its Deployment Assembly, to have the webmodule jar:ed inside WEB-INF/lib. dynwebapp contains a servlet filter that will call upon a class in webmodule. Default output folders (successful): - choose Debug > "Debug on Server" for dynwebapp and deploy it to a Tomcat 6 server - put a breakpoint inside webmodule:Main.hello() - surf to localhost:8080/dynwebapp RESULT: the debugger will break inside Main.hello and show the source location. Specified output folder (can't find source): - stop Tomcat - choose "Configure Build Path" for webmodule and go to the Source tab - tick "Allow output folders for source folders" - expand and click "Output folder" in the Source folders list - click Edit - tick "Specific output folder" - enter the same folder as default ("bin") - click OK - click OK to dismiss the Project Properties window - go into "Configure Build Path" once again to double-check that the "Allow output folder..." setting is still enabled (some choices make it untick itself) - start Tomcat again (dynwebapp is still deployed and breakpoint is in Main.hello) - surf to localhost:8080/dynwebapp RESULT: "Source not found" when breaking in Main.hello. Backing up to the filter class in dynwebapp will show the filter's source, but source from webmodule is not available.