Static content serving with WebLogic Server

If you need to server any kind of static content you always have to decide how to do this. This post describe the different ways of static content serving within a WebLogic server installation and gives you a brief idea where to look at and what your options are.

The problem
Imagine your brand new application. It is hype and provides large amounts of video and full quality images to your users. The filesize varies from few kb up to hundreds of megabyte. Imagine you have 1000 different resources available the size quickly rises up to hundreds of gigabyte. If you think about the time it takes to build and copy an application with such an amount of resources, you quickly notice that you are not willing to put them into your archive.war! But what are the options?

Static content through a webserver
The most obvious solution would be to skip the static content and leave it's handling to those optimized for it. Apache is the most well known representative from the group of professionals handling static content. You can use the WebLogic Webserver Plugins to decide on redirection rules. The static content will be served from the Apache and the configured dynamic content will be redirected to the WebLogic.
A simple example of packaging a separate content archive from your build with maven can be found in an earlier blogpost of mine.

Adv:
- fast content serving
- no war bundling
- option to do runtime changes

Disadv:
- no direct access from wls
- no wls security

Static content as library
Next option is to use weblogic shared libraries to bundle the static content. All you have to do is to package a content.war according to the shared libraries packaging conventions and deploy it to your server. Now you can reference the library from your application and use the contained resources. Read more about a simple but complete example in this blog post.

Adv:
- simple packaging and deployment
- use of all library features (e.g. versioning)
- wls security

Disadv:
- no direct access from wls
- large deployment

Static content as virtual directory
There is the weblogic specific web application deployment descriptor (weblogic.xml) that enables you to specify so called virtual directories. You can use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests. They do not necessarily have to be within your webpplication. You can specify any kind of directory on your server machine. This could look like this:

<wls:virtual-directory-mapping>
<wls:local-path>E:/virtualDirectory/content</wls:local-path>
<wls:url-pattern>/video/*</wls:url-pattern>
</wls:virtual-directory-mapping>

The WebLogic Server implementation of virtual directory mapping requires that you have a directory that matches the url-pattern of the mapping. The video example requires that you create a directory named E:/virtualDirectory/content/video.

Adv:
- fast content serving
- no war bundling
- option to do runtime changes
- wls security

Disadv:
-

Static content through a Dispatching Servlet
You can of course write your own resources servlet for delivering content, that lie in any filesystem. Of even find some examples on the web (e.g. Spring ResourceServlet).

Adv:
- no war bundling
- option to do runtime changes
- wls security

Disadv:
- wasting precious resources

Conclusion
Which solution to choose highly depends on you infrastructure and requirements. There are plenty of more advanced solutions (e.g. traffic cluster, caching) to optimize static content delivery which are not covered in this article. The most widespread solution to deliver large amounts of static content is the Webserver approach. As the word static denotes, it is all about non frequent changing content. This is nothing that should belong to the application server at all. But if you are forced to deliver through the appserver, you should try to use the most efficient method. I did not do any research on the performance of any of the approaches, but it seems obvious that the build in virutal-directory solution is the fastest one in terms of delivery.