castor
  1. castor
  2. CASTOR-1980

Castor cannot unmarshall xml documents which contain a xsi:type referring to an array "[..."

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 1.0.2, 1.1.1
    • Fix Version/s: None
    • Component/s: XML
    • Labels:
      None
    • Environment:
      JDK 1.6.0 and above
    • Number of attachments :
      0

      Description

      Due to a bug which has appeared in JDK 1.6.0 release (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149)
      Java will bug while trying to use the 'loadClass' method of the ClassLoader Class on an array classname
      ("[..." : e.g. "[I" array of int).

      So it's NOT a bug of Castor per se but can be blocking until the problem is fixed in the JDK/JRE. Until then, the fix at the Castor's
      codebase level is the following (file : castor-X.Y.Z/src/main/java/org/exolab/castor/xml/UnmarshalHandler.java)

      /**

      • Loads and returns the class with the given class name using the
      • given loader.
      • @param className the name of the class to load
      • @param loader the ClassLoader to use, this may be null.
      • *********************************************************************
      • PATCH : C.Assemat - 11/05/2007 due to the bug of loadClass in JDK 1.6
      • *********************************************************************
        **/
        private Class loadClass(String className, ClassLoader loader)
        throws ClassNotFoundException
        { // -- patch only if jdk 1.6 AND 'array class' if ( className.startsWith("[") ) return Class.forName(className); //-- use passed in loader else if ( loader != null ) return loader.loadClass(className); //-- use internal loader else if (_loader != null) return _loader.loadClass(className); //-- no loader available use Class.forName return Class.forName(className); }

        //-- loadClass

        Activity

        Hide
        Werner Guttmann added a comment -

        I am not sure that is the right fix, as it basically switches to another way of loading a class for all arrays. Rather than doing this, I'd limit the use of this scenario to JDK 6.0 only. And even if that's possible, I wonder how I woudl distinguish between scenarios where a Java 6 JVM has the bug and another one does not.

        Show
        Werner Guttmann added a comment - I am not sure that is the right fix, as it basically switches to another way of loading a class for all arrays. Rather than doing this, I'd limit the use of this scenario to JDK 6.0 only. And even if that's possible, I wonder how I woudl distinguish between scenarios where a Java 6 JVM has the bug and another one does not.
        Hide
        Christophe Assemat added a comment -

        Hi Werner,

        i agree. In fact my personal 'fix' check if the jdk version is >= 1.6 and apply the turnaround only in such a case. But
        i decided to not 'complicate' too much my explanation ...

        Anyway, i really hope that Sun will fix it quickly ...

        Show
        Christophe Assemat added a comment - Hi Werner, i agree. In fact my personal 'fix' check if the jdk version is >= 1.6 and apply the turnaround only in such a case. But i decided to not 'complicate' too much my explanation ... Anyway, i really hope that Sun will fix it quickly ...
        Hide
        Werner Guttmann added a comment -

        So how about the latter part of my question. Imagine I'd commit that change (enriched with the JDK >= 1.6 change). How would I - at run time - in three months time distinguish between a Java 6 JVM that has the bug and one that does not carry it any more ?

        Show
        Werner Guttmann added a comment - So how about the latter part of my question. Imagine I'd commit that change (enriched with the JDK >= 1.6 change). How would I - at run time - in three months time distinguish between a Java 6 JVM that has the bug and one that does not carry it any more ?
        Hide
        Christophe Assemat added a comment -

        Werner,

        as i say, it's not a bug of Castor, so the only thing you can do is watch for each new release
        of JDK 1.6 and check each time if the bug is still there. Let's say that the last version
        with the bug is (as an example !) 1.6.0_21 (and so that's the 1.6.0_22 has no more the bug), you will
        have to update the patch in such a way :

        if (jdk >= 1.6 && jdk <= 1.6021)
        => patch
        else
        => normal behavior

        What i mean here is that you are 'in some way' doom to have a java version dependent part of your code
        which is never a good practice of course or to warn users that Castor has such problem with JDK version 1.6 up to version 1.6.21.

        Show
        Christophe Assemat added a comment - Werner, as i say, it's not a bug of Castor, so the only thing you can do is watch for each new release of JDK 1.6 and check each time if the bug is still there. Let's say that the last version with the bug is (as an example !) 1.6.0_21 (and so that's the 1.6.0_22 has no more the bug), you will have to update the patch in such a way : if (jdk >= 1.6 && jdk <= 1.6021) => patch else => normal behavior What i mean here is that you are 'in some way' doom to have a java version dependent part of your code which is never a good practice of course or to warn users that Castor has such problem with JDK version 1.6 up to version 1.6.21.
        Hide
        rt@boschung added a comment -

        Hi all,
        Please consider this [email conversation between "Sunny Chan - Enterprise Java Engineering" and "Andrig (Andy) Miller - JBoss, a division of Red Hat"] :

        http://lists.jboss.org/pipermail/jboss-development/2007-June/009351.html

        Especially:
        "However I would suggested that for long term you should modify JBoss code to use alternative interface to get an array class, for example java.lang.reflect.Array.newInstance()."

        I hope you'll try also to follow this recommendation.

        ps.
        I try to find a solution as a short term solution, but as we use jnlp file, the workaround -Dsun.lang.ClassLoader.allowArraySyntax=true doesn't work. So we're blocked on jre1.5.

        Show
        rt@boschung added a comment - Hi all, Please consider this [email conversation between "Sunny Chan - Enterprise Java Engineering" and "Andrig (Andy) Miller - JBoss, a division of Red Hat"] : http://lists.jboss.org/pipermail/jboss-development/2007-June/009351.html Especially: "However I would suggested that for long term you should modify JBoss code to use alternative interface to get an array class, for example java.lang.reflect.Array.newInstance()." I hope you'll try also to follow this recommendation. ps. I try to find a solution as a short term solution, but as we use jnlp file, the workaround -Dsun.lang.ClassLoader.allowArraySyntax=true doesn't work. So we're blocked on jre1.5.

          People

          • Assignee:
            Unassigned
            Reporter:
            Christophe Assemat
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: