JiBX
  1. JiBX
  2. JIBX-409

NullPointerException during generate binding for class from other jar (added as dependency)

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JiBX 1.2.2
    • Fix Version/s: JiBX 1.2.3
    • Component/s: maven plugin
    • Labels:
      None
    • Environment:
      Windows XP, Java 1.6.0_20, Maven 3.0
      Mac OS X 10.6, Java 1.6.0_22, Maven 2.2.1
    • Number of attachments :
      3

      Description

      The problem is similar to JIBX-287, but I tested it with JiBX 1.2.2, and an unhandled Exception thrown.

      Stacktrace
      org.apache.maven.lifecycle.LifecycleExecutionException
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
      	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
      	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
      	at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
      	at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      	at java.lang.reflect.Method.invoke(Method.java:597)
      	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
      	at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
      	at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
      	at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      Caused by: org.apache.maven.plugin.MojoExecutionException
      	at org.jibx.maven.CompileBindingMojo.compile(CompileBindingMojo.java:224)
      	at org.jibx.maven.CompileBindingMojo.execute(CompileBindingMojo.java:173)
      	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
      	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
      	... 17 more
      Caused by: java.lang.NullPointerException
      	at org.jibx.binding.classes.ClassFile.<init>(ClassFile.java:242)
      	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:411)
      	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:443)
      	at org.jibx.binding.def.ObjectBinding.<init>(ObjectBinding.java:294)
      	at org.jibx.binding.def.BindingBuilder.unmarshalObjectBinding(BindingBuilder.java:1077)
      	at org.jibx.binding.def.BindingBuilder.unmarshalMapping(BindingBuilder.java:1815)
      	at org.jibx.binding.def.BindingBuilder.unmarshalMappings(BindingBuilder.java:1170)
      	at org.jibx.binding.def.BindingBuilder.unmarshalBindingDefinition(BindingBuilder.java:2169)
      	at org.jibx.binding.Utility.loadBinding(Utility.java:319)
      	at org.jibx.binding.Utility.loadFileBinding(Utility.java:439)
      	at org.jibx.binding.Compile.compile(Compile.java:217)
      	at org.jibx.maven.CompileBindingMojo.compile(CompileBindingMojo.java:221)
      	... 20 more
      

      The attached projects are the same as in JIBX-287, except the version of JiBX

      1. error.log
        67 kB
        Adam Biczok

        Activity

        Don Corley made changes -
        Field Original Value New Value
        Assignee Don Corley [ doncorley ]
        Hide
        Don Corley added a comment -

        Adam,

        Thank you so much for including these examples. It makes all the difference in trying to understand your question.

        Remember, JiBX is such an elegant solution for XML binding because there are no messy extra classes or generated source code. JiBX actually changes the bytecode of your class so it can generate XML. This means that JiBX is run right after compilation and before (jar) packaging.

        Typically, maven does the following in a JiBX binding project:
        1. Compiles your source code into class files.
        2. JiBX modifies the class files (bytecode) so they can generate the XML defined by your binding definition.
        3. Packages the class files into a jar, etc.

        In your example, just move the source files from the dsk-model project to the dsk-binding project, and JiBX runs flawlessly.

        I can't think of a situation where you would want to do the binding in a different project than the source files since you would be changing the class files in another project.

        Does this make sense?

        Thanks,

        Don

        Show
        Don Corley added a comment - Adam, Thank you so much for including these examples. It makes all the difference in trying to understand your question. Remember, JiBX is such an elegant solution for XML binding because there are no messy extra classes or generated source code. JiBX actually changes the bytecode of your class so it can generate XML. This means that JiBX is run right after compilation and before (jar) packaging. Typically, maven does the following in a JiBX binding project: 1. Compiles your source code into class files. 2. JiBX modifies the class files (bytecode) so they can generate the XML defined by your binding definition. 3. Packages the class files into a jar, etc. In your example, just move the source files from the dsk-model project to the dsk-binding project, and JiBX runs flawlessly. I can't think of a situation where you would want to do the binding in a different project than the source files since you would be changing the class files in another project. Does this make sense? Thanks, Don
        Don Corley made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        No Matter added a comment - - edited

        The same exception occurred in v1.2.4
        NPE is not the best to understand a problem.

        Show
        No Matter added a comment - - edited The same exception occurred in v1.2.4 NPE is not the best to understand a problem.

          People

          • Assignee:
            Don Corley
            Reporter:
            Adam Biczok
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: