Hi there,
While the pluggability support in Servlet 3.0 has made my life a lot
easier, I do still find it to be a somewhat limited. In 3.0, all
resources have to be bundled inside META-INF/resources inside a jar in
WEB-INF/lib in the deployed war. I think this is a bit rigid and that
we would benefit from adding more flexibility in resource loading.
My particular use case is to support plugin based architectures on the
Servlet/JSP platform. For these kinds of applications, it it desirable
to distribute apps and plugins independently. It is inconvenient
having to reassemble the application war file just to add or upgrade a
plugin. I should be possible to add it by dropping it in a folder.
I'd like to propose an addition to the JSR-340 which would enable the
loading of resources from arbitrary locations outside the war file.
Implementations could load resources from jar files outside the war,
from paths on the file system or even from non-file based sources. For
the purpose having something to base our discussion on, I'll throw out
a design idea here:
-----------------------------------------------
- New interface ResourceLoader:
package javax.servlet.ResourceLoader;
interface ResourceLoader {
URL getResource(String path);
Set getResourcePaths(String path);
InputStream getResourceAsStream(String path);
}
(The methods will behave similar to their cousins in
javax.servlet.ServletContext, just being scoped to a single
ResourceLoader)
- New method addResourceLoader(ResourceLoader resourceLoader) in
javax.servlet.ServletContext which will register a ResourceLoader for
use in the servlet context.
- New web.xml / web-fragment.xml syntax:
<resource-loader>
<resource-loader-class>..</resource-loader-class>
</resource-loader>
- Change javax.servlet.ServletContext methods getResource,
getResourcePaths and getResourceAsStream to consider registered
resource loaders in addition to the resources found in the war and in
META-INF/resources. Resource loaders would be consulted in the order
of their registration.
-----------------------------------------------
I'm very interested in hearing objections, ideas for
alternative/improved/simpler designs, security concerns or other
considerations. There's probably no shortage of things I haven't
thought of :-)
Looking forward to your comments!
Thanks,
Eirik.