jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Warner Onstine <wonst...@vmsinfo.com>
Subject Re: some WebDAV issues
Date Tue, 02 Sep 2008 15:11:42 GMT
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
>>
>


Mime
View raw message