Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
problems with JiBX and DM Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • problems with JiBX and DM

    Hi all!

    I have a problem using JiBX within Spring DM. I have a jibx runtime bundle and my client bundle that includes precompiled jibx classes. Versions do match because I packaged jibx runtime myself using the same (latest) version as for compiling.

    However at runtime I get

    JiBXException: Classloader conflict for binding factory 'foo.test.JiBX_bindingFactory' - factory does not implement required interface

    I checked my client bundle - the class is there, I assume that it implements everything correctly because it was generated by JiBX compiler. When I digged into jibx code I found that it tries to perform some things on such a class via reflection and in case of any exception throws its own exception with this text.

    Therefore I assume that the problem is that JiBX bundle does not see my bundle classes (that is quite expected as JiBX bundle knows nothing about my client bundle - it neither imports nor requires it). So the question is - what do I do in this case? Is there anyway to share my bundle's classes with an imported one (jibx).

    Or maybe my assumption is wrong - then why the hack do I get that exception? =)

  • #2
    I've got the sources, fired up my debugger and have now more details. This is the code fragment from org.jibx.runtime.BindingDirectory that throws this error:
    Code:
    try {
                Class factory = loader.loadClass(name);
                Method method = factory.getMethod(FACTORY_INSTMETHOD, EMPTY_ARGS);
                result = method.invoke(null, (Object[])null);
            } catch (SecurityException e) {
                ex = e;
            } catch (ClassNotFoundException e) {
                ex = e;
            } catch (NoSuchMethodException e) {
                ex = e;
            } catch (IllegalAccessException e) {
                ex = e;
            } catch (InvocationTargetException e) {
                ex = e;
                incompat = true;
            } finally {
                if (ex == null) {
                    if (result instanceof IBindingFactory) {
                        // ommited
                    } else {
                        throw new JiBXException
                            ("Classloader conflict for binding factory '" + name +
                            "' - factory does not implement required interface");
                    }
        // ommited
    the 'name' variable is 'foo.test.JiBX_bindingFactory' the classloader is my bundle's classloader (foo.test) so it must see this class without problems

    however there is some exception thrown because after this line
    Code:
    Class factory = loader.loadClass(name);
    execution falls directly into the finally block with ex == null and result == null. That is strange because there are a lot of exception types to be caught and it seems that this exception is not one of them.

    I tried to evaluate
    Code:
    loader.loadClass(name)
    in 'Expressions' view in STS to view the exception it gets but strangely it doesn't evaluate anything at all (even something like 2+2 - just shows blank result).

    P.S. I use Virgo 2.1.1 if that is to be mentioned

    === update ===

    OK, I finally found the source of problem when I faced it again. The problem is that JiBX instrumented classes are extending some classes from org.jibx.runtime.impl package which I thought was private, so I did neither export or import it. Hope that helps someone =)
    Last edited by shutyaev; Jun 25th, 2012, 03:54 PM.

    Comment

    Working...
    X