Projects:Static Resources Caching/Specs

Functional Requirements

The main functional goal of this project is to keep the log-in process of the backend working as usual, but by reducing the cost of loading the static resources (javascript and css) requested by the application.

To know more about how Openbravo processes the code of the static resources, see here.

Technical Specs

The objective is to reduce the number of request and time spent to generate the static resources (javascript and css).

Keeping this is mind, a new class will be created in core: StaticResourceProvider. This class will allow to keep the information needed to cache the static resources for the different applications like the ERP, WebPOS and other mobile applications.

Caching Javascript resources

The javascript resources are loaded in two steps. First, a request to the StaticResourceComponent is done. This is the class in charge of generating the static javascript resources.

The StaticResourceComponent concatenates all the javascript resources in one large file. Besides, the name of this file is generated by computing the MD5 of all the javascript content. The component will write the script code in the index.jsp page. Eventually, this results in another request to retrieve the generated file.

Note that before this project the file is generated once (having no modules in in development status) but the file name is computed in every request to the StaticResourceComponent.

After the first successful login, with the new cache mechanism both request will be avoided:

• The first request will be prevented by using the new StaticResourceProvider class which will keep in memory the name of the generated javascript file. Having this name cached, the file can be requested directly.
• When requesting the file, as it has already been requested before, the browser will retrieve it using its own memory cache avoiding this second request.

This mechanism is similar to the one being used in WebPOS module, with the MobileStaticResourceComponent class. For this reason, this class will be refactored to make use of the StaticResourceProvider. Thus, all the components providing static resources will be using a common caching infrastructure.

Caching CSS resources

In the same way as in the case of the javascript resources, the css resources are all concatenated before delivering them to the client. In this case the class in charge of this task is the StyleSheetResourceComponent.

One slight difference is that this component does not generate a file but returns a string with all the content. Thus, in order to cache this content with the browser the Etag in the header of the request to the component is used.

Before this project, the Etag is based on the module versions when there are no modules in in development status. In other case a random value is generated, i.e., cache is prevented.

Two modifications will be applied to this component, when there are no modules in in development status:

• The css content will be cached using the StaticResourceProvider. This way they will be computed once, on the first successful login.
• The Etag will be computed based on the css content by computing its corresponding MD5 hash.

Invalidating the Cache

In case it is necessary to invalidate the cache of the StaticResourceProvider class one of the following alternatives can be taken:

• Restart Tomcat
• Invalidate the information of a particular static resource using a JMX agent.

Regarding this second alternative, it is possible because the StaticResourceProvider has been declared as a MBean. Together with this, the new OBManagementFactory class is available which provides an API to register MBeans by using the MBean server.