some WebDAV issues

[Warner Onstine <wo...@vmsinfo.com>]

Hi all,
We are currently using the following setup:
- Extended org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet to  
provide our own repo
- Implemented our own LoginModule
- Implemented our own AccessManager
- Implemented our own Principal

Before doing the last two we were able to connect to the default  
repository and drop new files and folders no problem.

Initially I created a new LoginModule which allowed me to hook into  
our own authentication service. Then I created our own version of the  
AccessManager to control who has access to specific workspaces/folders.

When I did the AccessManager I pretty much followed the  
SimpleAccessManager and modified it. I'm not sure what may have  
changed but here is the behavior now.

1) Connect to the WebDAV repo and workspace (via OS X)
2) In the logs it logs in the user again and again, repeatedly  
obtaining a new session from our authentication server (I've tried a  
couple of things to get it to stop to no avail so far)
3) Once it's connected I attempt to add a file and I keep getting this  
error "An older version of [File] is already here would you like to  
replace it?"
4) Choosing 'Yes' does not push the file to the repo, it will just  
spin for a while and then die

Any suggestions on these two issues would be greatly appreciated.

-warner

Re: some WebDAV issues

[Warner Onstine <wo...@vmsinfo.com>]

Anyone else successfully using a Filter like this? The filter itself  
is simple, but I think that there might be some sort of conflict.

-warner

On Aug 26, 2008, at 8:28 AM, Warner Onstine wrote:

> Ahh, it looks like some kind of servlet filter setup issue as I just  
> swapped out our custom for the old SimpleAccessManager/LoginModule  
> and am still seeing the behavior. We currently have a main servlet  
> called adsite and then underneath we have this setup:
>
> web.xml snippets
>       <filter>
> 		<filter-name>RepoFilter</filter-name>
> 		<filter-class>com.webapp.webdav.filter.RepoFilter</filter-class>
> 	</filter>
>
>
>      <filter-mapping>
>        <filter-name>RepoFilter</filter-name>
>        <url-pattern>/repository/*</url-pattern>
>    </filter-mapping>
>
> (and this might be screwing stuff up, not sure - it's our Single  
> Sign On Login Filter for the rest of the app )
> <filter-mapping>
>        <filter-name>SSOLoginFilter</filter-name>
>        <url-pattern>/*</url-pattern>
>    </filter-mapping>
>
>
>
>    <listener>
>        <listener-class>com.vms.adsite.listeners.WebDAVListener</ 
> listener-class>
>    </listener>
>
>    <servlet>
>        <servlet-name>Webdav</servlet-name>
>        <servlet-class>com.webapp.webdav.WebDAVServlet</servlet-class>
>        <init-param>
>            <param-name>resource-path-prefix</param-name>
>            <param-value>/repository</param-value>
>        </init-param>
>        <init-param>
>            <param-name>resource-config</param-name>
>            <param-value>/WEB-INF/config.xml</param-value>
>        </init-param>
>        <load-on-startup>4</load-on-startup>
>    </servlet>
>    <servlet-mapping>
>        <servlet-name>Webdav</servlet-name>
>        <url-pattern>/repository/*</url-pattern>
>    </servlet-mapping>
>
> The RepoFilter is fairly simple:
>
> public class RepoFilter implements Filter {
>
>
> 	public void destroy() {
> 	}
>
> 	public void doFilter(ServletRequest request, ServletResponse  
> response,
> 			FilterChain chain) throws IOException, ServletException {
>        HttpServletRequest httpRequest = (HttpServletRequest) request;
>        RequestDispatcher dispatcher =  
> httpRequest.getRequestDispatcher("");
> 		dispatcher.forward(httpRequest, response);
> 	}
>
> 	public void init(FilterConfig filterConfig) throws ServletException {
> 	}
>
> }
>
> As is the listener:
> public class WebDAVListener implements ServletContextListener {
>
>
>    public void contextInitialized(ServletContextEvent event) {
>        ApplicationContextUtil.initializeContext("com/webapp/myapp/ 
> app-context.xml");
>        Properties props = (Properties)  
> ApplicationContextUtil.getBean("properties");
>        String configFile = props.getProperty("configFile");
>        String repHomeDir = props.getProperty("repHomeDir");
>
>        Hashtable env = new Hashtable();
>        env.put(Context.INITIAL_CONTEXT_FACTORY,  
> "org.apache.jackrabbit.core.jndi"
>                + ".provider.DummyInitialContextFactory");
>        env.put(Context.PROVIDER_URL, "localhost");
>        InitialContext ctx = null;
>        try {
>            ctx = new InitialContext(env);
>            RegistryHelper.registerRepository(ctx, "repo",  
> configFile, repHomeDir, true);
>            ServletContext sc = event.getServletContext();
>            sc.setAttribute("context", ctx);
>        }
>        catch (Exception e) {
>            ErrorHandler.dispose(e);
>        }
>    }
>
>    public void contextDestroyed(ServletContextEvent event) {
>
>    }
> }
>
>
> And Servlet:
> public class WebDAVServlet extends SimpleWebdavServlet {
>
>    public Repository getRepository() {
>        return WebDAVUtils.getRepo(getServletContext());
>
>    }
>
> }
>
> Any insight as to what's killing the writing to the WebDAV folder is  
> greatly appreciated. Basically what is happening is just what I  
> described. I try and drop a file or folder onto the shared folder  
> then it claims that an older version of the file already exists and  
> do I want to replace it. If I choose yes it spins for a bit and then  
> gives up. Initially when I drop the file on there it shows up in the  
> folder for a second or two then disappears.
>
> I am not seeing anything in the logs to clue me into what could be  
> intercepting this transfer so any help is greatly appreciated.
>
> And just like other db-driven webapps we also have a  
> TransactionFilter but it matches against different URL patterns  
> (like /app, *.page, etc.).
>
> -warner
>
> On Aug 26, 2008, at 12:42 AM, Angela Schreiber wrote:
>
>> Warner Onstine wrote:
>>> Hi all,
>>> We are currently using the following setup:
>>> - Extended org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet  
>>> to provide our own repo
>>> - Implemented our own LoginModule
>>> - Implemented our own AccessManager
>>> - Implemented our own Principal
>>> Before doing the last two we were able to connect to the default  
>>> repository and drop new files and folders no problem.
>>
>> so, it seems that your custom impl of accessmgr or loginmodule
>> introduced some problem, doesn't it?
>> [...]
>>
>>> When I did the AccessManager I pretty much followed the  
>>> SimpleAccessManager and modified it. I'm not sure what may have  
>>> changed but here is the behavior now.
>>
>> [...]
>>
>>> Any suggestions on these two issues would be greatly appreciated.
>>
>> did you check the logs?
>> please be more specific about the problem you are facing.
>>
>> thanks
>> angela
>>
>

Re: some WebDAV issues

[Warner Onstine <wo...@vmsinfo.com>]

Ahh, it looks like some kind of servlet filter setup issue as I just  
swapped out our custom for the old SimpleAccessManager/LoginModule and  
am still seeing the behavior. We currently have a main servlet called  
adsite and then underneath we have this setup:

web.xml snippets
        <filter>
		<filter-name>RepoFilter</filter-name>
		<filter-class>com.webapp.webdav.filter.RepoFilter</filter-class>
	</filter>


       <filter-mapping>
         <filter-name>RepoFilter</filter-name>
         <url-pattern>/repository/*</url-pattern>
     </filter-mapping>

(and this might be screwing stuff up, not sure - it's our Single Sign  
On Login Filter for the rest of the app )
<filter-mapping>
         <filter-name>SSOLoginFilter</filter-name>
         <url-pattern>/*</url-pattern>
     </filter-mapping>



     <listener>
         <listener-class>com.vms.adsite.listeners.WebDAVListener</ 
listener-class>
     </listener>

     <servlet>
         <servlet-name>Webdav</servlet-name>
         <servlet-class>com.webapp.webdav.WebDAVServlet</servlet-class>
         <init-param>
             <param-name>resource-path-prefix</param-name>
             <param-value>/repository</param-value>
         </init-param>
         <init-param>
             <param-name>resource-config</param-name>
             <param-value>/WEB-INF/config.xml</param-value>
         </init-param>
         <load-on-startup>4</load-on-startup>
     </servlet>
     <servlet-mapping>
         <servlet-name>Webdav</servlet-name>
         <url-pattern>/repository/*</url-pattern>
     </servlet-mapping>

The RepoFilter is fairly simple:

public class RepoFilter implements Filter {


	public void destroy() {
	}

	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain) throws IOException, ServletException {
         HttpServletRequest httpRequest = (HttpServletRequest) request;
         RequestDispatcher dispatcher =  
httpRequest.getRequestDispatcher("");
		dispatcher.forward(httpRequest, response);
	}

	public void init(FilterConfig filterConfig) throws ServletException {
	}

}

As is the listener:
public class WebDAVListener implements ServletContextListener {


     public void contextInitialized(ServletContextEvent event) {
         ApplicationContextUtil.initializeContext("com/webapp/myapp/ 
app-context.xml");
         Properties props = (Properties)  
ApplicationContextUtil.getBean("properties");
         String configFile = props.getProperty("configFile");
         String repHomeDir = props.getProperty("repHomeDir");

         Hashtable env = new Hashtable();
         env.put(Context.INITIAL_CONTEXT_FACTORY,  
"org.apache.jackrabbit.core.jndi"
                 + ".provider.DummyInitialContextFactory");
         env.put(Context.PROVIDER_URL, "localhost");
         InitialContext ctx = null;
         try {
             ctx = new InitialContext(env);
             RegistryHelper.registerRepository(ctx, "repo",  
configFile, repHomeDir, true);
             ServletContext sc = event.getServletContext();
             sc.setAttribute("context", ctx);
         }
         catch (Exception e) {
             ErrorHandler.dispose(e);
         }
     }

     public void contextDestroyed(ServletContextEvent event) {

     }
}


And Servlet:
public class WebDAVServlet extends SimpleWebdavServlet {

     public Repository getRepository() {
         return WebDAVUtils.getRepo(getServletContext());

     }

}

Any insight as to what's killing the writing to the WebDAV folder is  
greatly appreciated. Basically what is happening is just what I  
described. I try and drop a file or folder onto the shared folder then  
it claims that an older version of the file already exists and do I  
want to replace it. If I choose yes it spins for a bit and then gives  
up. Initially when I drop the file on there it shows up in the folder  
for a second or two then disappears.

I am not seeing anything in the logs to clue me into what could be  
intercepting this transfer so any help is greatly appreciated.

And just like other db-driven webapps we also have a TransactionFilter  
but it matches against different URL patterns (like /app, *.page, etc.).

-warner

On Aug 26, 2008, at 12:42 AM, Angela Schreiber wrote:

> Warner Onstine wrote:
>> Hi all,
>> We are currently using the following setup:
>> - Extended org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet  
>> to provide our own repo
>> - Implemented our own LoginModule
>> - Implemented our own AccessManager
>> - Implemented our own Principal
>> Before doing the last two we were able to connect to the default  
>> repository and drop new files and folders no problem.
>
> so, it seems that your custom impl of accessmgr or loginmodule
> introduced some problem, doesn't it?
> [...]
>
>> When I did the AccessManager I pretty much followed the  
>> SimpleAccessManager and modified it. I'm not sure what may have  
>> changed but here is the behavior now.
>
> [...]
>
>> Any suggestions on these two issues would be greatly appreciated.
>
> did you check the logs?
> please be more specific about the problem you are facing.
>
> thanks
> angela
>

Re: some WebDAV issues

[Angela Schreiber <an...@day.com>]

Warner Onstine wrote:
> Hi all,
> We are currently using the following setup:
> - Extended org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet to 
> provide our own repo
> - Implemented our own LoginModule
> - Implemented our own AccessManager
> - Implemented our own Principal
> 
> Before doing the last two we were able to connect to the default 
> repository and drop new files and folders no problem.

so, it seems that your custom impl of accessmgr or loginmodule
introduced some problem, doesn't it?
[...]

> When I did the AccessManager I pretty much followed the 
> SimpleAccessManager and modified it. I'm not sure what may have changed 
> but here is the behavior now.

[...]

> Any suggestions on these two issues would be greatly appreciated.

did you check the logs?
please be more specific about the problem you are facing.

thanks
angela