Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 303898

Summary: Help webapp broken due to org.eclipse.edc.scripting plug-in
Product: [Tools] CDT Reporter: Martin Oberhuber <mober.at+eclipse>
Component: cdt-debug-edcAssignee: Ken Ryall <ken.ryall>
Status: RESOLVED FIXED QA Contact: Ken Ryall <ken.ryall>
Severity: normal    
Priority: P3 CC: aleherb+eclipse, cdtdoug, cgold, ChrisAustin, ken.ryall, simon_kaegi
Version: 7.0   
Target Milestone: 7.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Screenshot of broken help webapp
none
Screenshot of Firebug "Net" tab with errors
none
Plug-in registry
none
Screenshot of plug-in Registry showing o.e.cdt.scripting none

Description Martin Oberhuber CLA 2010-02-25 08:34:16 EST
Created attachment 160181 [details]
Screenshot of broken help webapp

Build ID: Eclipse 3.6m5 + lots of add-ons (935 plug-ins in total)

When I launch a debuggee (Run As > Eclipse Application) and perform "Help > Help Contents" in the debuggee, the webapp cannot be used and does not show any icons. See attached screenshot for reference.

But in my host Eclipse, which uses exactly the same configuration, the help works just fine.

I have tried everything I could think of to track down the problem, but no luck so far. I'm wondering if there are any logs, tracing etc that could help finding the culprit? Or perhaps somebody has already seen the symptom?
Comment 1 Martin Oberhuber CLA 2010-02-25 09:12:10 EST
I should also mention that my host-eclipse uses "*.link" files in order to assemble plugins from several different extension locations.

I tried manually adding each of these extension locations in turn in my target platform. Initially it worked, but at some point it started failing. The odd thing is, even after I restored all extension locations to a state where it had worked before, it still consistently fails now.
Comment 2 Chris Austin CLA 2010-02-25 09:25:27 EST
We just had this same issue with one of our developing projects.  In our case, it was the result of conflicting alias mappings in for our Jetty instances.  That is to say, the help system is looking for requests off the root context, '/content', '/context', '/topic', etc.  Another component set up their jetty servlet to accept all requests from '/'.  Thus, the Help System came up, but every call to an image or js file was met with a file not found type response from our new component, because it of course wasn't hosting up these help resources.

So I would make sure you don't have conflicting jetty aliases within your product.  To see any error messages for the missing icon files, I would install and run Firebug in your Firefox instance, and this way you can watch the calls as they come in.  If you click on a call you can see what the server returned - it may help you narrow down the problem.
Comment 3 Martin Oberhuber CLA 2010-02-25 09:54:22 EST
Hm... I'd be very surprised if there were a 2nd Jetty servlet running since we are not doing anything particular with Jetty. But anyways, I got Firebug version 1.5.2, what now? How can I watch the calls / error messages?

Thanks a lot for your help!
Comment 4 Martin Oberhuber CLA 2010-02-25 10:00:38 EST
Created attachment 160187 [details]
Screenshot of Firebug "Net" tab with errors

Ok, I somehow got the "Net" tab opened. See attached the result of a refresh. Looks like the GIF images work, but quite a lot of the .js files return a 404 by the ProxyServlet.

What next?
Comment 5 Chris Goldthorpe CLA 2010-02-25 12:14:59 EST
Created attachment 160208 [details]
Plug-in registry

I concur with Chris Austin's theory. The images and javascript files will be affected if there are two bundles which create a resource mapping which aliases '/'. In this case it is non-deterministic as to which one takes priority so you could see strange results such as an infocenter which works fine the first time you launch it and fails to load images the next. Take a look in the plug-in registry and see if there is more than extension to
org.eclipse.equinox.http.registry.resources [HttpService resources] which has an alias of '/'. (see attachment) The fix is to add a service selector which applies that resource to only a particular server.
Comment 6 Martin Oberhuber CLA 2010-02-25 17:41:26 EST
Created attachment 160256 [details]
Screenshot of plug-in Registry showing o.e.cdt.scripting

Indeed! According to plug-in registry, it looks like an "org.eclipse.cdt.scripting" plug-in is the culprit...
Comment 7 Martin Oberhuber CLA 2010-02-25 17:45:39 EST
(In reply to comment #5)
> I concur with Chris Austin's theory. The images and javascript files will be
> affected if there are two bundles which create a resource mapping which aliases
> '/'. In this case it is non-deterministic as to which one takes priority

Could the experts in CDT explain why the org.eclipse.cdt.scripting plug-in thinks that it needs to register an extension to 
org.eclipse.equinox.http.registry.resources [HttpService resources] which has
an alias of '/', as per the source code here:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.scripting/plugin.xml?root=Tools_Project&view=markup

> The fix is to add a service selector which applies that resource to only a
> particular server.
Comment 8 Chris Goldthorpe CLA 2010-02-25 19:13:36 EST
Copying Simon Kaegi.

It seems that this is a problem we have run into on several occasions. The help system is setting a service selector on the org.eclipse.equinox.http.registry which makes those extensions only apply to the help server however any bundle that registers a resource alias of '/' can clash with the help system. I could make the problem less likely to occur by declaring separate aliases for /basic and /advanced which are where all the resources live so these more qualified aliases won out however it seems that maybe equinox should be giving priority to extensions which use a service selector over those which do not.
Comment 9 Martin Oberhuber CLA 2010-02-25 19:22:52 EST
What would have helped me most as a user, would have been a log entry of some sort when Jetty, equinox or whoever detects clashing alias extensions. 

In this case, both extensions registered "/" so it should have been known that the config is invalid, and this should have been logged with an indication what bundles contribute to the clash. Similar to the "Conflicting Keybindings" log entry in Eclipse today:

Warning
Tue Nov 17 13:29:19 CET 2009
Keybinding conflicts occurred.  They may interfere with normal accelerator
operation.

Warning
Tue Nov 17 13:29:19 CET 2009
A conflict occurred for CTRL+SHIFT+A:Binding(CTRL+SHIFT+A,
ParameterizedCommand(Command(org.eclipse.ui.project.buildProject,Build Project,
Build the selected project,
Category(org.eclipse.ui.category.project,Project,null,true),
ActionHandler(RetargetAction(buildProject)),
,,true),null),
org.eclipse.ui.defaultAcceleratorConfiguration,
org.eclipse.ui.contexts.window,,,system)
Binding(CTRL+SHIFT+A,
ParameterizedCommand(Command(org.eclipse.pde.ui.openPluginArtifact,Open Plug-in
Artifact,
Open a plug-in artifact in the manifest editor,
Category(org.eclipse.ui.category.navigate,Navigate,null,true),
org.eclipse.pde.internal.ui.search.dialogs.PluginArtifactSearchHandler,
,,true),null),
org.eclipse.ui.defaultAcceleratorConfiguration,
org.eclipse.ui.contexts.window,,,system)
Comment 10 Ken Ryall CLA 2010-02-26 01:33:32 EST
(In reply to comment #7) 
> Could the experts in CDT explain why the org.eclipse.cdt.scripting plug-in
> thinks that it needs to register an extension to 
> org.eclipse.equinox.http.registry.resources [HttpService resources] which has
> an alias of '/', as per the source code here:
> 
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.scripting/plugin.xml?root=Tools_Project&view=markup
>

I'm confused: the HttpService resources extension was a left-over from some sample code that we started with and was removed last Friday on the 19th:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.scripting/plugin.xml?root=Tools_Project&r1=1.1&r2=1.2

But your comment from the 25th suggests you are still seeing it in the plugin.xml.

There should be a new CDT build on the 26th, please try it and see if the problem is still there.

Sorry to inconvenience everyone with this oversight.
Comment 11 Martin Oberhuber CLA 2010-02-26 02:22:24 EST
Thanks Ken. We've been seeing the issue in our Target Platform which is CDT 7.0m5 so it looks like from your side this is fixed already.

I do think, though it is good that we discovered the issue since it prompts important improvement requests in other areas:
  - Platform/UA to register "/basic" and "/advanced" rather than "/"
  - Equinox Httpservice to log conflicts

I suggest filing clone bugs to get both of these addressed in the respective components, since it will help making the Platform more reliable.
Comment 12 Martin Oberhuber CLA 2010-02-26 17:34:05 EST
I have filed bug 304119 asking Platform/UA to register separate aliases,
and I have filed bug 304121 asking Equinox/Httpservice to better log clashes.

Since the original problem in CDT/EDC has been fixed, it looks like the bug can be marked as resolved with CDT 7.0m6. Right, Ken?
Comment 13 Ken Ryall CLA 2010-02-26 17:50:41 EST
Yes, this is fixed in the next CDT build.