Bug #2311

WidgetSet application

Added by Bernhard Fastenrath over 8 years ago. Updated over 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I have made a simple WidgetSet application with JWt 3.3.0 and Jetty 8.1.5.

It appears to work in Chrome, Safari, Opera and Firefox, but produces an error in Internet Explorer 9:

Wt internal error: [object Error], code: undefined, description: Could not complete the operation due to error 80020101.

The WidgetSet application apparently cannot find some of its resources:

[ResourceHandler] looking for /map.js/wt-resources/themes/default/wt.css

[ResourceHandler] looking for /map.js/wt-resources/themes/default/wt_ie.css

[ResourceHandler] looking for /map.js/wt-resources/webkit-transitions.css

"map.js" is the name of the script that is included from the main html page and that contains the WidgetSet application itself. The failure to find these resources also causes some display problems (e.g. missing images).


Updated by Bernhard Fastenrath over 8 years ago

The resource/display problem exists with all tested browsers, IE merely seems to have more of a problem, possibly because it requires an additional resource (wt_ie.css).


Updated by Bernhard Fastenrath over 8 years ago

Opera has the strange problem of ignoring a "new WBreak (this)"

in this WidgetSet application, and even a duplicate WBreak has no effect.


Updated by Koen Deforche over 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche
  • Target version set to 3.3.1


How does your deployment look like? Do you actually have a cross-domain setup (i.e. is the HTML on a separate page on separate server/port?).

If the resources cannot be fetched, then maybe your web.xml doesn't look okay. The mapping should end with '/*' to indicate ('including all sub paths').

If you get these strange CSS effects, perhaps the doctype of the HTML page isn't properly set or is some arcane doctype and not HTML5 ?

In any case, I've checked with JWt's helloworld widgetset example and that seems to work fine indicating that there is nothing obvious wrong in JWt itself.




Updated by Bernhard Fastenrath over 8 years ago

I don't have a web.xml. The mapping is:

ResourceHandler resource_handler = new ResourceHandler ();

resource_handler.setDirectoriesListed (false);

resource_handler.setWelcomeFiles (new String[] { "index.html" });

resource_handler.setResourceBase (directory.getPath ());

getHandlerList ().addHandler (resource_handler);

That should allow to traverse a directory tree.

I had indeed a vanilla HTML header, but changing it to HTML5 doesn't change anything.

I will have a look at your example and try to deduce what's different in my application.

It seems strange that JWt tries to access anything under the "/map.js/" path. That is the path of the script, of course it's not a directory name and it shouldn't be a directory name. So the attempt to access that is clearly a bug.


Updated by Bernhard Fastenrath over 8 years ago

I've tried to reset the internal path in my servlet, but that didn't help either:

public WApplication createApplication (WEnvironment env)


app = new WApplication (this.env = env);

app.setInternalPath ("/", true);




Updated by Bernhard Fastenrath over 8 years ago

And no, my application does not use cross-domain references. It is a very simple test scenario:

<!DOCTYPE html>



Updated by Bernhard Fastenrath over 8 years ago

has no effect either.


Updated by Bernhard Fastenrath over 8 years ago

WApplication uses the deployment path in getRelativeResourcesUrl() to construct a relative URL if the property WApplication.RESOURCES_URL is not set. The deployment path of the script is apparently the name of the script in this case, which is not useful. You could still make this a documentation bug. At least that doesn't seem to be very well explained.


Updated by Koen Deforche over 8 years ago

Hey Bernhard,

The way you setup your mapping doesn't look right. JWt does present itself as a directory of files --- it's a servlet and everything is dynamic (including all resources). It's a custom thing to present resources as URLs (including a directory structure). This goes back to the CGI PATH_INFO variable that was part of the very first CGI specfications. It's not a bug --- it's a (main) feature.

Either deploy as the standard examples or translate the web.xml literally into API like in:




Updated by Koen Deforche over 8 years ago

  • Status changed from Feedback to Rejected

Also available in: Atom PDF