ServletContextUriLocator not working with Spring mvc resources

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use Spring @MVC and resource to deliver static files when the Spring 
Dispatcher Servlet is the default servlet
2. Resources like /blah/css are mapped via <mvc:resources mapping="/**" 
location="/public/" cache-period="86400" />  to /public/css/blah.css

What is the expected output? What do you see instead?

The same behavior as in 1.4.4, wro4j finds the resources and works on them

What version of the product are you using? On what operating system?

Spring 3.1.1, Wro4j 1.4.5

Please provide any additional information below.

ServletContextUriLocator cannot validate the input stream in 

private void validateInputStreamIsNotNull(final InputStream inputStream, final 
String uri)
      throws IOException {
    if (inputStream == null) {
      LOG.error("Exception while reading resource from " + uri);
      throw new IOException("Exception while reading resource from " + uri);
    }

called in line 147:     inputStream = dispatcherFirstStreamLocator(uri);

Original issue reported on code.google.com by m...@planet-punk.de on 11 Apr 2012 at 9:52

[GoogleCodeExporter]

This is the log when i request an existing css files:

2012-04-11 12:10:13,837 DEBUG http-nio-8443-exec-10 DispatcherServlet:819 - 
DispatcherServlet with name 'dailyfratze' processing GET request for 
[/dailyfratze/css/reset-fonts-grids.css]
2012-04-11 12:10:13,838 DEBUG http-nio-8443-exec-10 
RequestMappingHandlerMapping:213 - Looking up handler method for path 
/css/reset-fonts-grids.css
2012-04-11 12:10:13,843 DEBUG http-nio-8443-exec-10 
RequestMappingHandlerMapping:223 - Did not find handler method for 
[/css/reset-fonts-grids.css]
2012-04-11 12:10:13,843 DEBUG http-nio-8443-exec-10 SimpleUrlHandlerMapping:169 
- Matching patterns for request [/css/reset-fonts-grids.css] are [/**]
2012-04-11 12:10:13,843 DEBUG http-nio-8443-exec-10 SimpleUrlHandlerMapping:193 
- URI Template variables for request [/css/reset-fonts-grids.css] are {}
2012-04-11 12:10:13,844 DEBUG http-nio-8443-exec-10 SimpleUrlHandlerMapping:124 
- Mapping [/css/reset-fonts-grids.css] to HandlerExecutionChain with handler 
[org.springframework.web.servlet.resource.ResourceHttpRequestHandler@33aefa25] 
and 1 interceptor
2012-04-11 12:10:13,844 DEBUG http-nio-8443-exec-10 DispatcherServlet:902 - 
Last-Modified value for [/dailyfratze/css/reset-fonts-grids.css] is: -1
2012-04-11 12:10:13,844 DEBUG http-nio-8443-exec-10 
ResourceHttpRequestHandler:161 - Trying relative path 
[css/reset-fonts-grids.css] against base location: ServletContext resource 
[/public/]
2012-04-11 12:10:13,845 DEBUG http-nio-8443-exec-10 
ResourceHttpRequestHandler:166 - Found matching resource: ServletContext 
resource [/public/css/reset-fonts-grids.css]
2012-04-11 12:10:13,845 DEBUG http-nio-8443-exec-10 
ResourceHttpRequestHandler:120 - Determined media type 'text/css' for 
ServletContext resource [/public/css/reset-fonts-grids.css]
2012-04-11 12:10:13,846 DEBUG http-nio-8443-exec-10 DispatcherServlet:957 - 
Null ModelAndView returned to DispatcherServlet with name 'dailyfratze': 
assuming HandlerAdapter completed request handling
2012-04-11 12:10:13,848 DEBUG http-nio-8443-exec-10 DispatcherServlet:913 - 
Successfully completed request

This i see when i request the css group that the file belongs to:

2012-04-11 12:11:18,569 ERROR http-nio-8443-exec-4 ServletContextUriLocator:199 
- Exception while reading resource from /css/reset-fonts-grids.css
2012-04-11 12:11:18,569  WARN http-nio-8443-exec-4 ServletContextUriLocator:156 
- Wrong or empty resource with location: /css/reset-fonts-grids.css
2012-04-11 12:11:18,570  WARN http-nio-8443-exec-4 PreProcessorExecutor:199 - 
Invalid resource found: 
ro.isdc.wro.model.resource.Resource@297c1d8f[CSS,/css/reset-fonts-grids.css,true
]

Furthermore i don't see wro4j requesting this file at all.

It is configured like so:

<group name="base">
        <css>/css/reset-fonts-grids.css</css>
</group>

Original comment by m...@planet-punk.de on 11 Apr 2012 at 10:12

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 11 Apr 2012 at 10:15

• Changed state: Accepted

[GoogleCodeExporter]

An additional hint:

<mvc:resources mapping="/**" location="/public/" cache-period="86400" />

maps all requests that don't match a controller to the location public, so 
/css/reset-fonts-grids.css becomes /public/css/reset-fonts-grids.css.

This used to work in 1.4.4 but not in 1.4.5 It seems to have something to do 
with the changes in ServletContextUriLocator

Original comment by m...@planet-punk.de on 11 Apr 2012 at 10:17

[GoogleCodeExporter]

Hm, i think i got the problem…

I'm using a secured connection on my development box as well.
1.4.4 had no problem with an invalid certificate.

That means i could call 
https://localhost:8443/dailyfratze/owr/dailyfratze-base-de.css without any 
problems.

On 1.4.5 this gives me an empty page.

If i call http://localhost:8080/dailyfratze/owr/dailyfratze-base-de.css on 
1.4.5 it works as expected.

So this morning when i tweeted you that everything worked i called the http 
version first and the the https. By then everything was cached. But when i call 
the https site first it doesn't work.

I can as a workaround import the self-signed certificate but i'd love to have 
the old behavior back if this is possible.

Original comment by m...@planet-punk.de on 11 Apr 2012 at 10:35

[GoogleCodeExporter]

That's interesting finding. 
The change to ServletContextUriLocator is this:
- instead of using dispatcher for locating a stream, open a connection to the 
resource (absolute path).
The reason problem with the original implementation was that it couldn't locate 
servlet context resources when a scheduler was invoked with updateCachePeriod 
greater than 0.

It is impossible to fix both problems at the same time. Probably allowing to 
configure ServletContextUriLocator with a strategy (old one and new one) would 
be the best approach.. But not sure what should be the default one.

Original comment by alex.obj...@gmail.com on 11 Apr 2012 at 11:11

[GoogleCodeExporter]

An additional strategy would be a good solution. Make the new one the default 
as it fits production use. The old one can be configured for dev/test only. 

Another solution would maybe an option to configure separate strategies for the 
scheduler and the "standard" request case so that maybe both problems can be 
addressed. 

Original comment by m...@planet-punk.de on 11 Apr 2012 at 3:00

[GoogleCodeExporter]

Interesting suggestion. However have to test if it is doable. 

Original comment by alex.obj...@gmail.com on 11 Apr 2012 at 3:05

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 11 Apr 2012 at 3:05

• Added labels: Milestone-Release-1.4.6

[GoogleCodeExporter]

The dispatcherStreamLocator implementation was rollbacked. 
Fixed in branch 1.4.x

Original comment by alex.obj...@gmail.com on 5 May 2012 at 4:19

• Changed state: Fixed