xgrr.de – the whole not the half

When I was playing around with Funambol last week I was brutally stopped by an Exception thrown somewhere in the code of the Funambol DS Server.

java.lang.NullPointerException
at com.funambol.server.session.SyncSessionHandler.processInitSyncMapMessage(SyncSessionHandler.java:905)
at com.funambol.server.session.SyncSessionHandler.processMessage(SyncSessionHandler.java:521)
at com.funambol.server.engine.SyncAdapter.processInputMessage(SyncAdapter.java:533)
at com.funambol.server.engine.SyncAdapter.processXMLMessage(SyncAdapter.java:254)
at com.funambol.transport.http.server.LocalSyncHolder.processXMLMessage(LocalSyncHolder.java:97)
at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:399)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilter.java:132)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.funambol.transport.http.server.SyncResponseTimeFilter.doFilter(SyncResponseTimeFilter.java:159)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Unknown Source)

I decided to make the effort and have a look at the code. That was actually what was taking me so long to fix the problem at hand. Today I got a fix on the actual problem. The offending code is in the handling of the session. When I configured my Funambol I supplied the URI of the service I want to create which is at this point in time not the real URI. What happens during the authentication handshake is that the session is bound to this specific URI. This means that if the client requests a specific URI the server overwrites this URI with the one set in Funambol.xml and the session is only valid for this URI.

During sync it is checked if the client is authenticated which is not the case or at least not for the URI specified in the Funambol.xml. In this case a clause in the code is reached which provokes the NullPointerException stated above.

If you have this problem, make sure that the URI in your Funambol.xml file is either empty (then the URI provided by the client is taken) or that your clients use the URI which is specified.