Pluggable resource loaders #2
Comments
|
@glassfishrobot Commented |
|
@glassfishrobot Commented http://java.net/projects/servlet-spec/lists/users/archive/2011-06/thread/1 |
|
@glassfishrobot Commented I'll upload a patch, but I need to review the code and do some more testing first. For now, here's a summary of changes/additions made: M deployment/schemas/src/main/resources/glassfish/lib/schemas/javaee_6.xsd Added support for new XML syntax com.example.. (I know these will need to be moved to the 3.1 / jeee7 versions of these files, but I decided not to do that now after a few failed attempts. A + deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/ResourceLoaderNode.java Changes related to parsing the new and nodes and representing them as an AppResourceLoaderDescriptor. I pretty much stole the code from since they're structurally the same. M web/javax.servlet/src/main/java/javax/servlet/ServletContext.java Added the ResourceLoader interface and ServletContext.addResourceLoader. M web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
M web/web-glue/src/main/java/com/sun/enterprise/web/TomcatDeploymentConfig.java Register the context's resource loaders by using the information available in AppResourceLoaderDescriptor |
|
@glassfishrobot Commented I've filed an issue in the Glassfish Jira for this, with some suggestions for improvements: |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented The project also includes a demo of hot deployment of JSPs from OSGi bundles. |
|
@glassfishrobot Commented Thinking about it, my resource loader proposal for Servlet 3.1 might I initially focused on a single tenant being able to dynamically I've uploaded a patch to the Jira issue which adds the ResourceLoader Finally, I've also uploaded a proof-of-concept web application. This |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
gregw
added
Enhancement
|
@gregw I would favor for the deployment model to stick to WAR file or WAR file exploded in a directory to be the 2 ways that have to be supported. Any other really should be left up to the vendor. |
While the pluggability support in Servlet 3.0 was a great improvement, I do still find it to be a somewhat limited. In 3.0, all resources have to be bundled inside META-INF/resources in 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 how resources can be loaded.
I suggest adding a provider interface to the servlet API which will allow implementors to load resources from arbitrary locations. That could be the file system, the network, OSGi bundles, the classpath, some generated in-memory representation or any other source which can locate and load resources.
How would this be useful? Our 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. It should be possible to add it simply by dropping it in a folder. In the same way, would like to add and remove plugins at runtime. Both of these requirements are impossible to implement with Servlet 3.0, but should be easy to implement with the proposed API.
Other use cases that comes to mind might be: sharing of resources across contexts, loading resources from source during development and being able to separate downloadable application data from the application itself.
Also note that the current Servlet 3.0 way of loading resources from /META-INF/resources on the classpath could be implemented as a resource loader in the suggested design. Likewise, the normal resource loading from the war file could also be modeled as a resource loader. So in a way, we already have multiple ways of loading resources, we just don't have a well defined name and concept around it that people can use. (Or rather framework developers, I don't see this as something the average developer will commonly have to deal with directly, they'll probably use a framework/library which supports it)
For the purpose of discussion, I'll throw out an initial design idea here:
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. "path" is the path being looked up.)
-
-
com.example.MyResourceLoaderNew 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:
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 about
The text was updated successfully, but these errors were encountered: