Wt

Call the WServer's readConfigurationProperty method. There is no WApplication object in the context of the call to handleRequest() in general (handleResource is called without grabbing the WApplication lock to which the resource belongs), and in particular not for static resources (since there is no relation at all to any WApplication instance).

You should be able to get the server object by calling WServer::instance() (in case you have only one server, which is usually the case).

Wim.

This surely is not as intended. Can you provide a small code example that demonstrates this problem?

Wim.

Here you are :)

Hey,

I see two weird things in this code.

Note that on one hand you have a WServer, and on the other hand you have a WApplication. Your WServer object stays alive during the time that your server is accessible, while a WApplication object is created when a session is started, and destroyed when a session terminates (either through timeout, explicit notification from the client, or by caling quit() on the WApplication object).

A static resource represents what has to happen when a global, static URL is accessed. Static resources configured on the WServer. During the lifetime of the WServer object, any request to the URL that it is bound to, will be handled by that resource. Therefore, we typically see static resources added in the same area where you call server.addEntryPoint(). By calling server.addResource() in each application constructor, as in your code example, you're re-configuring this static URL whenever an application is created, which is not correct. Session related resources do exist in Wt: these are the WResources that are not bound to a static URL. They will have a random URL, ensuring that they are only known to the browsers of the active session, and the URL is only valid as long as the WResource exist. Since the WResource will be deleted when the session is terminated, the URL becomes invalid when the session terminates.

By embedding the WResource as member in your WApplication object, and then registering it to WServer as handler for a static resource, you create a dangling pointer: session is created -> WResource is created and registered. You change the url in your browser -> browser notifies Wt that user goes away, Wt destroys the WApplication object which causes deletion of the WResource, browser accesses URL which is handled by a WResource that is deleted -> page fault.

Static resources must have a lifetime that lasts as long as they are accessible, this is typically the lifetime of your WServer object. So you could e.g. instantiate them in your main() function.

A second problem is the use of WTimer in the static resource. WTimer is a timer that runs in the browser of a user, and that will use JavaScript to initiate an event back to the server after a particular time. WTimer can thus not be used in a static resource, since there is no browser into play. If you want to user server-side timers, you will have to post them in the server's event loop. Get the ioservices related to the server, and schedule an event on the WIOService.

Wim.