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
