getting to resource under /WEB-INF

[feester]

I want to get to a file that is under /WEB-INF of my web application, but by means of a relative reference.

Using FileSystemResource, I can get to a file by providing a complete path like bean "myFile" below. But FileSystemResouce, apparently, cannot handle a relative path like:
<value>WEB-INF/data/targetFile.xxx</value>

QUESTION: how is a resource, under /WEB-INF, accessed by relative path?

I suspect the solution is something other than use of FileSystemResource.

-------------------------------------------------------------------------
<!-- file resource bean in contextResources.xml -->
<bean id="myFile" class="org.springframework.core.io.FileSystemResou rce">
<constructor-arg>
<value>C:/tomcat/webhosts/myVirtualHost/ROOT/WEB-INF/data/targetFile.xxx</value>
</constructor-arg>
</bean>

[feester]

I figured out how to do what I wanted, but in a cleaner way. I was originally creating a Resource bean and then passing it as property to a View bean. Now I just get a reference to the desired resource directly from the ApplicationContext.

My View bean inherits from AbstractView which implements ApplicationContextAware. So, to get reference to a file resource, in decendant View just do following:

getApplicationContext().getResource( "relativePathToTargetFile" );

The bean definition looks like this:

<bean id="viewName" class="xxx.MyView">
  <property name="targetFile"><value>WEB-INF/.../targetFile.xxx</value></property>
</bean>

[Keith Donald]

Feester,

You can also make the injected resource property for your view, currently accepting a String property I presume?, accept a Spring Resource instead. This is a bit more flexible, as you can easily vary the type of resource by using a resource prefix in your bean definition, for example classpath: or file:. Without a resource type prefix specified, *I believe* Spring will base the resource path relative to your deployment environment. This means starting at the webapp root directory in a web environment, and the classpath in a standalone application. I'm going on memory here a bit, but I'm pretty sure that's the case.

[Keith Donald]

I forgot to mention Spring has a default property editor installed for Resource properties, so you don't actually have to define a resource instance in the context definition. Just make your property of type Resource and use plain ol' string values to represent your resource paths. Spring will automatically resolve it to a Resource instance, again using the default strategy appropriate for your deployment environment (or a specific strategy if you specified a resource type prefix like classpath

Spring's Resource abstraction is quite elegant and one of the few unpublicized parts of the framework.

[james.estes]

What I don't like about this approach is that I am directly dependant on Spring. I realize in this case, the code is based on Spring code anyway...but I'm talking more generally here. This dependency is really becoming less and less an issue for me...but nonetheless I don't want to require Spring for my method signatures where I can avoid it.

I have an issue in JIRA that proposes a post-processor approach. It takes the code from PropertyPlaceholderConfigurer and extracts it into a PlaceholderConfigurer (so that Placeholder type post processors can be made more easily). Then has an implementation that would resolve placeholders like "${res:/WEB-INF/blah.xml}" with the ResourceLoader (applicationContext.getResource) and return the external form of the URL to the resource found. Since it delegates to the ResourceLoader, the default one would also be able to resolve things like "${res:classpath:com/foo/blah.xml}"

http://opensource.atlassian.com/proj...browse/SPR-260
(be sure and read all the comments...I probably posted the issue too quickly...)

[feester]

kdonald,

I tried what you indicated and it worked! I like it. (It hadn't occured to me that Spring would resolve a string <value> in <property> element to the type of the setter method, i.e. Resource.) This allows for a single bean descriptor for my View implementation.

Thanks for the feedback.

Jim

[2devnull]

I forgot to mention Spring has a default property editor installed for Resource properties, so you don't actually have to define a resource instance in the context definition. Just make your property of type Resource and use plain ol' string values to represent your resource paths. Spring will automatically resolve it to a Resource instance, again using the default strategy appropriate for your deployment environment (or a specific strategy if you specified a resource type prefix like classpath

Spring's Resource abstraction is quite elegant and one of the few unpublicized parts of the framework.

Can someone point me to sample code for this? Thanks

[maramonar]

What I don't like about this approach is that I am directly dependant on Spring. I realize in this case, the code is based on Spring code anyway...but I'm talking more generally here. This dependency is really becoming less and less an issue for me...but nonetheless I don't want to require Spring for my method signatures where I can avoid it.

I have an issue in JIRA that proposes a post-processor approach. It takes the code from PropertyPlaceholderConfigurer and extracts it into a PlaceholderConfigurer (so that Placeholder type post processors can be made more easily). Then has an implementation that would resolve placeholders like "${res:/WEB-INF/blah.xml}" with the ResourceLoader (applicationContext.getResource) and return the external form of the URL to the resource found. Since it delegates to the ResourceLoader, the default one would also be able to resolve things like "${res:classpath:com/foo/blah.xml}"

http://opensource.atlassian.com/proj...browse/SPR-260
(be sure and read all the comments...I probably posted the issue too quickly...)

Hi James and all:
Could you give me to an example of a configuration file using ${res:/web-inf/xx.xml}?
The property type would have to be String or URL?
Thanks for your time.