Announcement Announcement Module
No announcement yet.
mvc:resources and war on Weblogic Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • mvc:resources and war on Weblogic

    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.SimpleUrlHandlerMapping - Matching patterns for request [/resources/jquery/1.4/jquery.js] are [/resources/**]
    DEBUG: org.springframework.web.servlet.handler.SimpleUrlHandlerMapping - URI Template variables for request [/resources/jquery/1.4/jquery.js] are {}
    DEBUG: org.springframework.web.servlet.handler.SimpleUrlHandlerMapping - Mapping [/resources/jquery/1.4/jquery.js] to HandlerExecutionChain with handler [org.springframework.web.servlet.resource.ResourceHttpRequestHandler@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.ResourceHttpRequestHandler - Trying relative path [jquery/1.4/jquery.js] against base location: ServletContext resource [/resources/]
    DEBUG: org.springframework.web.servlet.resource.ResourceHttpRequestHandler - No matching resource found - returning 404
    Any idea what's gone wrong and how best to fix it?

    Last edited by David Kerwick; Jan 28th, 2011, 10:01 AM.

  • #2
    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:

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


    • #3
      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?



      • #4
        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?


        • #5
          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


          • #6
            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@2165121 - appName: 'test', name: 'test', context-path: '/test', spec-version: '2.5'" failed, Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2547' bytes..
   Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2547' bytes.
                    at weblogic.servlet.internal.ServletOutputStreamImpl.ensureContentLength(
                    at weblogic.servlet.internal.ServletResponseImpl.ensureContentLength(
                    at weblogic.servlet.internal.ServletResponseImpl.send(
                    at Source)
                    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.


            • #7
              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.


              • #8
                The issue is #SPR-7706. Workarounds?


                • #9
                  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.



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

                    in place of:

                    <mvc:resources mapping="/resources/**" location="/resources/" />
                    This gets the default directory structure working on weblogic and Tomcat. YMMV.


                    • #11
                      The reason is explained here:

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