On Sun, 2012-03-25 at 18:59 +0200, Tobias Hägele wrote: > Hallo, > > seit etlichen Tagen schlägt der Sync mit Syncevolution fehl. > Da es möglicherweise am Server liegt, hier eine genauere Beschreibung > des Fehlers incl. log: > https://core.forge.funambol.org/ds/viewMessage.do?dsForumId=405&dsMessageId=191031 > > .
</pre></p><p><b>root cause</b> <pre>org.jibx.runtime.JiBXException: For input string: "X-SYNTHESIS-RESTART" org.jibx.runtime.Utility.parseDigits(Utility.java:155) org.jibx.runtime.Utility.parseInt(Utility.java:218) com.funambol.framework.core.SyncType.JiBX_binding_unmarshal_1_0(SyncType.java) X-SYNTHESIS-RESTART is a special value that SyncEvolution puts into the DevInf/Datastore/SyncCap XML fields. Those are defined as a list of PCDATA strings and thus may hold arbitrary strings. But the Funambol server seems to assume that they contain only integer values (as they usually do) and thus runs into the parser exception. I've looked at the source code of /org/jibx/runtime/Utility.java [1], it cannot be cheated to accept a leading number followed by a unique string. The high road would be to ask Funambol to remove this incorrect assumption in their server. I think they already extended their own SyncCap list with special numeric codes, which they could change to strings. The low road is to use numeric codes in SyncEvolution+libsynthesis. There is no central registry for those codes, so there is a certain risk that different vendors end up choosing the same number range for different things. Strings avoid that problem. I'm going to answer on the Funambol list, but I wouldn't be surprised if they don't want to change anything. It's quite complicated to change (needs to be done on clients and servers) and doesn't help their core business (Funambol client to server sync). [1] http://grepcode.com/file/repo1.maven.org/maven2/org.jibx/jibx-run/1.2.3/org/jibx/runtime/Utility.java#Utility.parseDigits%28java.lang.String%2Cint%2Cint%29 -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
