JiBX
  1. JiBX
  2. JIBX-289

Possible class loading conflicts of precompiled bindings

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JiBX 1.2.1
    • Fix Version/s: JiBX 1.2.2
    • Component/s: core
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I'm working with maven 2.0.9 and JiBX 1.2.1.

      I've reported on the error previously at
      http://www.mail-archive.com/jibx-users%40lists.sourceforge.net/msg03932.html

      It's being generated at BindingDirectory.getFactory(String bname,
      String pack, ClassLoader loader), line 273

      "if (result instanceof IBindingFactory) {"

      "result" is loaded via a class loader initialized in
      "org.jibx.binding.classes.ClassFile.setPaths(String[] paths)", line
      2048:

      s_directLoader = new URLClassLoader(urls);

      This classloader's parent classloader is the system class loader.

      However IBindingFactory is loaded by RealmClassLoader which is part of
      the Classworks clsas loading framework used by Maven.

      There are two fixes that in both cases should be considered according
      to the use of the binding compiler. Both set the parent class loader to
      the UrlClassLoader that loads the bindings:

      s_directLoader = new
      URLClassLoader(urls,ClassFile.getClass().getClassLoader());

      or

      s_directLoader = new URLClassLoader(urls,
      Thread.currentThread().getContextClassLoader());

      In both cases "result" which is the binding factory generated for the
      precompiled project, is loaded via the parent class loaders which
      s_directLoader will delegate to, thus, the "result instanceof
      IBindingFactory" succeeds.

      I tested both solutions using the Maven JiBX plugin 1.2.1, Maven Antrun
      plugin and invoking directly the compiler via the command line
      successfully.

        Activity

        Hide
        Louis B added a comment -

        Any update on this issue, as I am running into the same problem, and have been unable to find another work around.

        Show
        Louis B added a comment - Any update on this issue, as I am running into the same problem, and have been unable to find another work around.
        Hide
        Dennis Sosnoski added a comment -

        So if I understand this correctly, the problem occurs when trying to compile a binding using precompiled bindings with maven. The code which loads the precompiled binding information uses the ClassFile classloader, which only works off URLs and ignores the maven Classworks classloader.

        The code has been changed for the 1.2.2 release to have the ClassFile classloader use ClassFile.class.getClassLoader() as the parent classloader, so based on your tests this should take care of the problem.

        Show
        Dennis Sosnoski added a comment - So if I understand this correctly, the problem occurs when trying to compile a binding using precompiled bindings with maven. The code which loads the precompiled binding information uses the ClassFile classloader, which only works off URLs and ignores the maven Classworks classloader. The code has been changed for the 1.2.2 release to have the ClassFile classloader use ClassFile.class.getClassLoader() as the parent classloader, so based on your tests this should take care of the problem.

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Karel A Sague
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: