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

  • mvc:resources and war on Weblogic

    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

    Code:
    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?

    Thanks
    David
    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:

    Code:
    	<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)

    Comment


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

      Code:
      <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

      Comment


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

        Comment


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

          Comment


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


            Code:
            <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, 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:422)
                    at weblogic.servlet.internal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1416)
                    at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1459)
                    at weblogic.servlet.internal.ServletRequestImpl.run(Unknown 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.

            Comment


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

              Comment


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

                Comment


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

                  Code:
                  <resources mapping="/resources/**" location="classpath:/resources/" />
                  And serve out resources the old way.

                  David

                  Comment


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

                    Code:
                    <mvc:default-servlet-handler/>
                    in place of:

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

                    Comment


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

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

                      Comment

                      Working...
                      X