Rajiv,
>> 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.
>
> So are you suggesting that we define a standard location for such a folder
> and the
> mechanism to associate an application with a particular folder?
The use case with jar files in a folder was something I mentioned just
to give a more concrete example how pluggable resource loading can be
useful in real life. But as Greg mentions, the design allows providers
to load resources from arbitrary locations. That could be the file
system, the network OSGi bundles, some in-memory representation or the
classpath.
The Servlet 3.0 way of loading resources from /META-INF/resources on
the classpath could be implemented as a ResourceLoader in the
suggested design. Likewise, the default resource loading from the war
file could also be modelled as a ResourceLoader. 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)
>> interface ResourceLoader {
>> URL getResource(String path);
>> Set getResourcePaths(String path);
>> InputStream getResourceAsStream(String path);
>> }
>
> Would the "path" above would be a URI or an absolute file system path?
> The path would point to a jar file?
The path parameter is the path being looked up and as such has much
the same semantics as the methods in ServletContext.
>> 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 :-)
>
> Will have to think a little more about this before making more comments.
> In the mean time please file a JIRA issue with this so we cant track it.
Thanks, will do!
Eirik.