Announcement Announcement Module
Collapse
No announcement yet.
DispatcherServlet/ServletWrappingController with JackRabbit SimpleWevdavServlet Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • DispatcherServlet/ServletWrappingController with JackRabbit SimpleWevdavServlet

    Hello:

    After some testing and a fruitful thread on the JackRabbit Forum I found a problem with what I'm trying to do. To cut a long story short, what I'm trying to do is using SimpleWevdavServlet wrapped in a DispatcherServlet/ServletWrappingController, "injecting" a bean configured repository in my SimpleWevdavServlet using the Spring WebApplicationContext.

    So now I actually achieve that, but unfortunately there are some problems specific to the Spring side of the equation. Basically, the OPTIONS method is handled not by the SimpleWevdavServlet (which returns the headers identifing a webdav resource) but somewhere *before*, in Dispatcher or HandlerMapping or ServletWrappingController. As actually are the PUT and DELETE methods, from what I saw so far.

    So the question is, how can I make sure that all the requests are dispatched to my wrapped servlet, maintaining the functionality of accessing my beans through injection and/or the WebApplicationContext?

    Thanks in advance.

  • #2
    In your DispatcherServlet include a parameter named 'dispatchOptionsRequest' and set it to 'true'. If you don't the OPTIONS is ignored. The other methods will be passed to the DispatcherServlet.

    Comment


    • #3
      I've done that and upgraded to 2.5.3 (I was using 2.5) and there's a different behaviour, but not what I wanted.

      if i do a OPTIONS to http://localhost:8080 it returns indeed a http 200 with

      <header key="Allow" value="GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS"/>

      but if i do a OPTIONS to my wrapped servlet return a

      HTTP/1.1 405 Request method 'OPTIONS' not supported

      I'll try to investigate more tomorrow.

      Thanks for your prompt reply.

      Comment


      • #4
        After testing, I found out that the only difference using OPTION with my wrapped servlet is

        dispatchOptionsRequest = true -> return 405

        dispatchOptionsRequest = false -> return 200

        but neither of then get's to my servlet. The only methods that reach my servlet are GET, POST and HEAD.

        Note that if I declare my servlet in web.xml (without wrapping it in Spring) the OPTIONS behave as expected, returning a DAV header and the full range of DAV methods in Allow.

        I'll try to step the Spring sources to see where the OPTIONS is getting trapped.

        If in the meantime you can suggest anything it will be much appreciated.

        Cheers.

        Comment


        • #5
          Happily enough it seems that the download page / CVS repository are down. Is there a mirror anywhere?

          Comment


          • #6
            Well, after some waiting and debugging and stuff, I see that when my OPTION request gets to the ServletWrappingController.checkAndPrepare(), it hits on the supportedMethods, that contains only [GET, POST, HEAD], wich is actually consistent with my prior testings, and thus throws a HttpRequestMethodNotSupportedException.

            Now I don't know if this is only a consequence of a prior problem, like some failing configuration when instantiating the ServletWrappingController, but I'll (try to) check it.

            I say this because I do see that this.supportedMethods = new HashSet(4); so there is room for another method, maybe OPTION didn't get there although I do have
            Code:
            <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
            		<init-param>
            			<param-name>dispatchOptionsRequest</param-name>
            			<param-value>true</param-value>
            		</init-param>
            But then again I need all the DAV methods to pass through.

            In the meanwhile I wonder if extend the ServletWrappingController will be a option for me.

            Comment


            • #7
              What probably makes sense here is that on instantiation of ServletWrappingController, a OPTION was sent to the wrapped servlet and the Allow methods be allowed (!).

              However I do see the WebContentGenerator allows for a number of methods, so that will be already possible...

              Comment


              • #8
                Well, doing this

                Code:
                public class WebdavServletWrappingController extends ServletWrappingController {
                
                	public WebdavServletWrappingController() {
                
                		String[] m = { "OPTIONS", "GET", "HEAD", "POST", "TRACE", "PROPFIND",
                				"PROPPATCH", "MKCOL", "COPY", "PUT", "DELETE", "MOVE", "LOCK",
                				"UNLOCK", "VERSION-CONTROL" };
                
                		setSupportedMethods(m);
                
                	}
                }
                it seems to work fine, but it's not very elegant, to say the least...

                However I have now some errors on the DAV side - "501 Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet API" - so I guess I "vou pregar para outra freguesia" as they say in my country...

                Comment


                • #9
                  Actually I think the problem is not with JCR but somehow between JBoss and Spring. When I try to connect DAVExplorer here is what I got.

                  Code:
                  ========= Outbound Message =========
                  OPTIONS /webdav/repotest/archive/ HTTP/1.1
                  Host: localhost:8080
                  Connection: TE
                  TE: trailers, deflate, gzip, compress
                  User-Agent: UCI DAV Explorer/0.91 RPT-HTTPClient/0.3-3E
                  Translate: f
                  Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
                  Authorization: Basic YWFhOmFhYQ==
                  
                  
                  ========= Inbound Message =========
                  HTTP/1.1 200 OK
                  Server: Apache-Coyote/1.1
                  DAV: 1,2,version-control,version-history,label
                  Allow: OPTIONS, GET, HEAD, POST, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, PUT, DELETE, MOVE, LOCK, UNLOCK, VERSION-CONTROL
                  MS-Author-Via: DAV
                  Content-Length: 0
                  Date: Thu, 01 May 2008 14:59:17 GMT
                  
                  
                  ========= Outbound Message =========
                  PROPFIND /webdav/repotest/archive/ HTTP/1.1
                  Host: localhost:8080
                  Connection: TE
                  TE: trailers, deflate, gzip, compress
                  User-Agent: UCI DAV Explorer/0.91 RPT-HTTPClient/0.3-3E
                  Depth: 1
                  Translate: f
                  Authorization: Basic YWFhOmFhYQ==
                  Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
                  Content-type: text/xml
                  Content-length: 345
                  
                  <?xml version="1.0"?>
                  <A:propfind xmlns:A="DAV:">
                      <A:prop>
                          <A:displayname/>
                          <A:resourcetype/>
                          <A:getcontenttype/>
                          <A:getcontentlength/>
                          <A:getlastmodified/>
                          <A:lockdiscovery/>
                          <A:checked-in/>
                          <A:checked-out/>
                          <A:version-name/>
                      </A:prop>
                  </A:propfind>
                  
                  ========= Inbound Message =========
                  HTTP/1.1 501 Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet API 
                  Server: Apache-Coyote/1.1
                  Content-Type: text/html;charset=utf-8
                  Content-Length: 1232
                  Date: Thu, 01 May 2008 14:59:17 GMT
                  Connection: close
                  So the DAV is doing a OPTION that is returning correctly and immediatly after a PROPFIND that fails, but that actually never reaches the DispatcherServlet and consequently my servlet.

                  I even put a filter in the middle

                  Code:
                  		if (((HttpServletRequest) arg0).getMethod().equals("PROPFIND")) {
                  			config.getServletContext().getRequestDispatcher("/propfind/*")
                  					.forward(arg0, arg1);			
                  		} else {
                  			arg2.doFilter(arg0, arg1);
                  		}
                  (with several variations) but when PROPFIND it seems the call is catched somewhere and returns the error immedialtly. If I comment the config... line I get a error saying the PROPFIND BODY is empty...

                  I also removed the servlets and filters from the default web.xml but still not works.

                  Also, if I use only my servlet without the DispatcherServlet/ServletWrappingController everithing works fine.

                  Help, anyone?

                  Cheers.

                  Comment


                  • #10
                    I FOUND IT!!! (or at least I think I found it)

                    Basically, to cut a long story short, when using my extended SimpleWebdavServlet alone it worked OK and when wrapped in ServletWrappingController and accessed though the DispatcherServlet gives that PROPFIND error is because while SimpleWebdavServlet implements service(req, resp), the DispatcherServlet never did it, so the webdav specific methods where being catch by the HttpServlet.service() that returned the 501 errors.

                    Now I just added in the overridden service

                    Code:
                    	protected void service(HttpServletRequest req, HttpServletResponse resp)
                    			throws ServletException, java.io.IOException {
                    		try {
                    			doService(req, resp);
                    		} catch (Exception e) {
                    			// TODO Auto-generated catch block
                    			e.printStackTrace();
                    		}
                    	}
                    and now IT WORKS!

                    Now that's incredible how after so much trouble to find it, the solution seems so easy and obvious...

                    Comment


                    • #11
                      I was wondering if I should report this as a bug, or a improvement or something, as it may affect others in the future?

                      However, I only tested my specific cases so I don't know if such a change can have negative impact elsewhere in the framework, but that has to be the development team to evaluate.

                      Cheers.

                      Comment


                      • #12
                        Hello again.

                        I finally opened a Jira with this issue in

                        http://jira.springframework.org/browse/SPR-4799

                        Cheers.

                        Comment


                        • #13
                          final code and config

                          If it's not too much trouble, can you post your final code and configuration? I am doing POC jackrabbit integration...

                          Comment


                          • #14
                            Hi:

                            All the code I have changed is what appears in the Jira, and I have no special configuration whatsoever. BTW, what's POC?

                            Cheers.

                            Comment


                            • #15
                              Originally posted by amsmota View Post
                              Hi:

                              All the code I have changed is what appears in the Jira, and I have no special configuration whatsoever. BTW, what's POC?

                              Cheers.
                              proof of concept

                              Comment

                              Working...
                              X