mvc:resources and war on Weblogic

[David Kerwick]

Hi,
For some reason when I deploy a war file on weblogic Spring mvc:resources doesn't seem to work. This works fine as a war on Tomcat. To make sure it wasn't me I downloaded the mvc-showcase, did a maven package and deployed on Weblogic (10.3). I get the errors below even though the files are in the war file


DEBUG: org.springframework.web.servlet.DispatcherServlet - DispatcherServlet with name 'appServlet' processing GET request for [/mvc-showcase-1.0.0-BUILD-SNAPSHOT/resources/jquery/1.4/jquery.js]
DEBUG: org.springframework.web.servlet.handler.SimpleUrlH andlerMapping - Matching patterns for request [/resources/jquery/1.4/jquery.js] are [/resources/**]
DEBUG: org.springframework.web.servlet.handler.SimpleUrlH andlerMapping - URI Template variables for request [/resources/jquery/1.4/jquery.js] are {}
DEBUG: org.springframework.web.servlet.handler.SimpleUrlH andlerMapping - Mapping [/resources/jquery/1.4/jquery.js] to HandlerExecutionChain with handler [org.springframework.web.servlet.resource.ResourceH ttpRequestHandler@206a920] and 2 interceptors
DEBUG: org.springframework.web.servlet.DispatcherServlet - Last-Modified value for [/mvc-showcase-1.0.0-BUILD-SNAPSHOT/resources/jquery/1.4/jquery.js] is: -1
DEBUG: org.springframework.web.servlet.resource.ResourceH ttpRequestHandler - Trying relative path [jquery/1.4/jquery.js] against base location: ServletContext resource [/resources/]
DEBUG: org.springframework.web.servlet.resource.ResourceH ttpRequestHandler - No matching resource found - returning 404

Any idea what's gone wrong and how best to fix it?

Thanks
David

[alexhutnik]

Just ran in to this problem an hour ago. Problem is that Weblogic comes with limited default mime type mappings.
Add some more to your web.xml. Example:


<mime-mapping>
<extension>js</extension>
<mime-type>text/javascript</mime-type>
</mime-mapping>

My problem now is that it seems the jsessionid is changing with every request... (unrelated to the mime type issue)

[David Kerwick]

Hi,
Thanks for that, unfortunately it didn't work for me. I added that mime type, but it loads nothing from the resources folder js, css or any image.

I moved the whole resource folder under WEB-INF/classes and used


<mvc:resources mapping="/resources/**" location="classpath:/resources/"/>

Which worked but seems very ugly.

I take it you have no such issue with a war on Weblogic?

Thanks
David

[alexhutnik]

I do the same resource mapping in my app. I just have a resources folder in WEB-INF and throw all my static content in there. I don't have any issues in Tomcat but in Weblogic it needed the mime type mapping.

Your issue might stem from request mapping perhaps?

[David Kerwick]

The mapping seems to work as I can see it being picked up in the log file. I think this might be a feature of Weblogic and how it handles war files. I think when it goes to load a file what it considers the 'root' directory is different from Tomcat. Looks like Weblogic is looking in WEB-INF and Tomcat in the 'webapp' i.e. root of the war file.
I assume this is the same thing as a classloader issue.
I don't know how to get them to play nice together so I've gone back to the old way of loading resources.

Thanks again
David

[David Kerwick]

Well as an extension to this I deployed on Weblogic in exploded format.
That seemed to work but it turned out it only worked every second request for me, which seems very weird.

The second request gives the error



<02-Feb-2011 14:05:48 o'clock GMT> <Error> <HTTP> <BEA-101104> <Servlet execution in servlet context "weblogic.servlet.internal.WebAppServletContext@216 5121 - appName: 'test', name: 'test', context-path: '/test', spec-version: '2.5'" failed, java.net.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2547' bytes..
java.net.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2547' bytes.
at weblogic.servlet.internal.ServletOutputStreamImpl. ensureContentLength(ServletOutputStreamImpl.java:4 22)
at weblogic.servlet.internal.ServletResponseImpl.ensu reContentLength(ServletResponseImpl.java:1416)
at weblogic.servlet.internal.ServletResponseImpl.send (ServletResponseImpl.java:1459)
at weblogic.servlet.internal.ServletRequestImpl.run(U nknown Source)
at weblogic.work.ExecuteThread.execute(ExecuteThread. java:201)
Truncated. see log file for complete stacktrace
>

A refresh works, second one doesn't, etc...

Don't know which side it acting weird Spring or Weblogic at this stage.

[hafthor]

Had this problem too. Moving the resources under classpath and adding mime types helped, but then I ended up with the every-other-request failed problem too. Turns out this is a cache problem. I believe some part of the stack is correctly determining that the client browser doesn't need the content, but instead of a 304 being returned, a completely blank response is returned, causing the browser to not display anything, but also to discard the item in cache so the next time the If-Modified-Since header is not sent. I'm trying to chase this problem down now.

[hafthor]

The issue is #SPR-7706. Workarounds?

[David Kerwick]

Hi,
I only had that problem when I deployed in exploded format, moving it into the classpath in a war seems to have solved it for me. The other option would be just to remove


<resources mapping="/resources/**" location="classpath:/resources/" />

And serve out resources the old way.

David

[zephon]

I was able to resolve this issue by using the configuration:


<mvc:default-servlet-handler/>

in place of:


<mvc:resources mapping="/resources/**" location="/resources/" />

This gets the default directory structure working on weblogic and Tomcat. YMMV.

[aprades]

The reason is explained here: https://jira.springsource.org/browse/SPR-8461

The workaround is to deploy the app as an exploded ear.