Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2 RC1
    • Component/s: None
    • Labels:
      None
    • keywords:
      xeclipse new connection
    • Similar issues:
      XECLIPSE-28Connection persistence
      XECLIPSE-173Can't connect to (sub) wiki
      XECLIPSE-66Space names are not displayed correctly when connecting to XWiki 1.2
      XECLIPSE-153Preview browser should use authentication credentials as set on navigator's connection object
      XECLIPSE-120NullPointerException thrown when connecting to a just started XWiki.
      XECLIPSE-147UI emprovements to new connection's XMLRPC URL endpoint.
      XECLIPSE-22Make XWiki connections persistent between Eclipse restarts
      XECLIPSE-135XEclipse should recreate the index files if it they are missing in the connection directory
      XECLIPSE-108Delete a Connection not implemented
      XECLIPSE-71Connections are not restored

      Description

      After a fresh install of XWiki I ran XEclipse 1.1 standalone version and the plugin version, trying to connect to the XWiki using user "Admin", password "admin".
      Both implementations could not connect to the XWiki, giving the following exception:

      org.xwiki.eclipse.model.XWikiConnectionException: org.xwiki.eclipse.model.impl.XWikiDAOException: org.codehaus.swizzle.confluence.SwizzleConversionException: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"
      at org.xwiki.eclipse.model.impl.XWikiPlainConnection.connect(Unknown Source)
      at org.xwiki.eclipse.wizards.NewConnectionWizard$1.run(Unknown Source)
      at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
      Caused by: org.xwiki.eclipse.model.impl.XWikiDAOException: org.codehaus.swizzle.confluence.SwizzleConversionException: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"
      at org.xwiki.eclipse.model.impl.XWikiRemoteDAO.<init>(Unknown Source)
      ... 3 more
      Caused by: org.codehaus.swizzle.confluence.SwizzleConversionException: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"
      at org.codehaus.swizzle.confluence.ConfluenceObjectConvertor.revert(ConfluenceObjectConvertor.java:56)
      at org.codehaus.swizzle.confluence.MapConvertor.revert(MapConvertor.java:39)
      at org.codehaus.swizzle.confluence.Confluence.revert(Confluence.java:791)
      at org.codehaus.swizzle.confluence.Confluence.getPage(Confluence.java:127)
      ... 4 more
      Caused by: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"
      at java.text.DateFormat.parse(DateFormat.java:355)
      at org.codehaus.swizzle.confluence.ConfluenceObjectConvertor.revert(ConfluenceObjectConvertor.java:53)
      ... 7 more

      Also tried with different, newly created username, same thing.

        Activity

        Hide
        Fabio Mancinelli added a comment -

        Unfortunately this is not directly related to XEclipse bug, but it's a bug of the Swizzle libraries used by XEclipse.

        In fact, the 'org.codehaus.swizzle.confluence.SwizzleConversionException: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"' is the real cause.
        From what I understand what happens is that XEclipse is running in a "French-localized environment" while the XWiki is running in a "English localized environment".

        Swizzle uses a language dependent way for transfrorming the date to a string by encoding also the day and month names.
        So when the server receives "mer. juil." it doesn't know how to parse it because it expects "Wed Jul". Hence the exception.

        This is a very big flaw in Swizzle that affects both client and server side.

        The solution could be to run XEclipse using the English locale.

        Show
        Fabio Mancinelli added a comment - Unfortunately this is not directly related to XEclipse bug, but it's a bug of the Swizzle libraries used by XEclipse. In fact, the 'org.codehaus.swizzle.confluence.SwizzleConversionException: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007"' is the real cause. From what I understand what happens is that XEclipse is running in a "French-localized environment" while the XWiki is running in a "English localized environment". Swizzle uses a language dependent way for transfrorming the date to a string by encoding also the day and month names. So when the server receives "mer. juil." it doesn't know how to parse it because it expects "Wed Jul". Hence the exception. This is a very big flaw in Swizzle that affects both client and server side. The solution could be to run XEclipse using the English locale.
        Hide
        Vincent Massol added a comment -

        Fabio, a good idea might be to raise it in Swizzle's JIRA?

        Show
        Vincent Massol added a comment - Fabio, a good idea might be to raise it in Swizzle's JIRA?
        Hide
        Fabio Mancinelli added a comment -

        Actually this is a serious flaw in the current implementation of XMLRPC in XWiki that makes the current implementation completely broken.
        The problem identified by Enygma is more complicated and is a bug that has been introduced in the "patched" version used in XWiki (and XEclipse): swizzle-confluence-1.1-20070908-xwiki.jar.
        Probably the original Swizzle implementation at CodeHaus does not suffer from this bug.

        What happens is the following: communication on XMLRPC is done by transforming every object into its String representation.
        This is done by the ConfluenceObjectConvertor.

        Standard Java types are converted using toString() calls, but when it comes to Date objects, serialization is done using SimpleDateFormat objects.
        Things are fine if both the client and the server use the same locale. In fact, SimpleDataFormat is locale dependent, hence the problem.

        To the rescue there is an IdentityObjectConvertor that basically does not perform any conversion.
        There is also an XWiki-XMLRPC function to set this as the conversion mechanism: setNoConversion().
        Unfortunately, due to an error in the implementation, this method is useless.

        In fact, when an XMLRPC method is called what happens is that the XMLRPC servlet initializes the XMLRPC handler (i.e. ConfluenceRpcHandler) by calling its init method.
        But in ConfluenceRpcHandler.init there is a setConvertor(new MapConvertor(new ConfluenceObjectConvertor()));

        So basically when I call setNoConversion, the current convertor is set to IdentityObjectConvertor for map's fields, but at the next XMLRPC call, the init method will reset it to ConfluenceObjectConvertor making the setNoConversion useless.

        This means that currently XEclipse (or any client using swizzle-confluence-1.1-20070908-xwiki.jar) will work only if the client and server side are using the same locale, and there's no way to make them work in the other cases.

        The new XMLRPC infrastructure will solve this issue, but will still suffer of this locale bug unless there is a not-to-messy way to discover the remote XWiki version and locale in order to force Date conversions to be in that locale.

        Show
        Fabio Mancinelli added a comment - Actually this is a serious flaw in the current implementation of XMLRPC in XWiki that makes the current implementation completely broken. The problem identified by Enygma is more complicated and is a bug that has been introduced in the "patched" version used in XWiki (and XEclipse): swizzle-confluence-1.1-20070908-xwiki.jar. Probably the original Swizzle implementation at CodeHaus does not suffer from this bug. What happens is the following: communication on XMLRPC is done by transforming every object into its String representation. This is done by the ConfluenceObjectConvertor. Standard Java types are converted using toString() calls, but when it comes to Date objects, serialization is done using SimpleDateFormat objects. Things are fine if both the client and the server use the same locale. In fact, SimpleDataFormat is locale dependent, hence the problem. To the rescue there is an IdentityObjectConvertor that basically does not perform any conversion. There is also an XWiki-XMLRPC function to set this as the conversion mechanism: setNoConversion(). Unfortunately, due to an error in the implementation, this method is useless. In fact, when an XMLRPC method is called what happens is that the XMLRPC servlet initializes the XMLRPC handler (i.e. ConfluenceRpcHandler) by calling its init method. But in ConfluenceRpcHandler.init there is a setConvertor(new MapConvertor(new ConfluenceObjectConvertor())); So basically when I call setNoConversion, the current convertor is set to IdentityObjectConvertor for map's fields, but at the next XMLRPC call, the init method will reset it to ConfluenceObjectConvertor making the setNoConversion useless. This means that currently XEclipse (or any client using swizzle-confluence-1.1-20070908-xwiki.jar) will work only if the client and server side are using the same locale, and there's no way to make them work in the other cases. The new XMLRPC infrastructure will solve this issue, but will still suffer of this locale bug unless there is a not-to-messy way to discover the remote XWiki version and locale in order to force Date conversions to be in that locale.
        Hide
        Eduard Moraru added a comment -

        After analyzing in the upper provided log I notice this line:

        org.osgi.framework.language=en
        user.country=GB
        user.language=en

        This would mean and should mean that my Eclipse instance is using the english locale (as my KDE is configured also to use english).
        The obvious conclusion would be that the downloaded and installed XWiki version would have its locale set to french.

        Am I wrong?

        Show
        Eduard Moraru added a comment - After analyzing in the upper provided log I notice this line: org.osgi.framework.language=en user.country=GB user.language=en This would mean and should mean that my Eclipse instance is using the english locale (as my KDE is configured also to use english). The obvious conclusion would be that the downloaded and installed XWiki version would have its locale set to french. Am I wrong?
        Hide
        Robert Lindsay added a comment -

        The LOCALE is being set to FR in the start command; change it to en_US.utf8 (or whatever you have for locale) and it works

        Show
        Robert Lindsay added a comment - The LOCALE is being set to FR in the start command; change it to en_US.utf8 (or whatever you have for locale) and it works
        Hide
        Eduard Moraru added a comment -

        Indeed!

        If you edit the "/usr/local/XWiki Enterprise/start_xwiki.sh" file (as default installed path)...

        from:
        LANG=fr_FR.ISO8859-1 java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT -Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar

        to:
        LANG=en_US.utf8 java $JAVA_OPTS -Dfile.encoding=utf8 -Djetty.port=$JETTY_PORT -Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar

        ...as my current locale is set for instance, everything works ok.

        It is a workaround, but not one to be put into practice.

        Shouldn't XWiki's default locale be set to en_US.utf8 or something related to that? I consider it would be more widespread.
        Or even determined (the system's locale) at install time and edited into the start_xwiki.sh file?

        And regarding the version and locale, can't they be fetched on every new connection, trough a server-side xmlrpc function or just plainly pushed by the server to every new connection?
        Or another way, it could be included in the result of something like the Confluence.getServerInfo() method if possible.

        Show
        Eduard Moraru added a comment - Indeed! If you edit the "/usr/local/XWiki Enterprise/start_xwiki.sh" file (as default installed path)... from: LANG=fr_FR.ISO8859-1 java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT -Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar to: LANG=en_US.utf8 java $JAVA_OPTS -Dfile.encoding=utf8 -Djetty.port=$JETTY_PORT -Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar ...as my current locale is set for instance, everything works ok. It is a workaround, but not one to be put into practice. Shouldn't XWiki's default locale be set to en_US.utf8 or something related to that? I consider it would be more widespread. Or even determined (the system's locale) at install time and edited into the start_xwiki.sh file? And regarding the version and locale, can't they be fetched on every new connection, trough a server-side xmlrpc function or just plainly pushed by the server to every new connection? Or another way, it could be included in the result of something like the Confluence.getServerInfo() method if possible.
        Hide
        Fabio Mancinelli added a comment -

        A clean, simple and effective solution would be to pass to XMLRPC directly Date objects instead of their String representation.
        XMLRPC supports the Date data-type and it handles all the conversions seamlessly (and correctly)

        This, however, would break compatibility with older versions of XWiki that expect Dates passed as Strings. (see the previous comment about the setNoConversion() issue)

        Show
        Fabio Mancinelli added a comment - A clean, simple and effective solution would be to pass to XMLRPC directly Date objects instead of their String representation. XMLRPC supports the Date data-type and it handles all the conversions seamlessly (and correctly) This, however, would break compatibility with older versions of XWiki that expect Dates passed as Strings. (see the previous comment about the setNoConversion() issue)
        Hide
        Sergiu Dumitriu added a comment -

        The default language should be en_US, indeed, but for the encoding it is a bit more difficult. It is planned to switch to UTF-8 in the future, but it is a hard migration.

        Show
        Sergiu Dumitriu added a comment - The default language should be en_US, indeed, but for the encoding it is a bit more difficult. It is planned to switch to UTF-8 in the future, but it is a hard migration.
        Hide
        Fabio Mancinelli added a comment -

        Fixed.

        This was due to a bug in the implementation of the underlying XMLRPC layer.

        Show
        Fabio Mancinelli added a comment - Fixed. This was due to a bug in the implementation of the underlying XMLRPC layer.

          People

          • Assignee:
            Fabio Mancinelli
            Reporter:
            Eduard Moraru
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: