JiBX
  1. JiBX
  2. JIBX-422

NullPointerExceptions and wrong paths when using the JiBX Maven plugin

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: JiBX 1.2.2, JiBX 1.2.3
    • Fix Version/s: None
    • Component/s: maven plugin
    • Labels:
      None
    • Environment:
      Ubuntu Linux, Maven 3 something
    • Number of attachments :
      0

      Description

      I have been trying to get the Maven-JiBX plugin to work on a project I work on. The binding files are in src/main/binding

      With maven-jibx-plugin 1.2.3, jibx-run 1.2.2 and jibx-extras 1.2.2 in the dependencies, I get:

      Caused by: java.lang.NullPointerException
      	at org.jibx.binding.classes.MungedClass.checkDirectory(MungedClass.java:238)
      	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:405)
      	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:443)
      	at org.jibx.binding.def.ObjectBinding.<init>(ObjectBinding.java:294)
      

      With maven-jibx-plugin 1.2.2, jibx-run 1.2.2 and jibx-extras 1.2.2 in the dependencies, I get:

      Caused by: java.io.FileNotFoundException: .../.hudson/jobs/<jobname>/workspace/<project>/target/classes/config/<project>/bindings/<project>/JiBX_binding_<project>_request_commonFactory.class (No such file or directory)
      	at java.io.FileOutputStream.open(Native Method)
      	at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
      	at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
      	at org.jibx.binding.classes.ClassFile.writeFile(ClassFile.java:1999)
      	at org.jibx.binding.classes.MungedClass.writeChanges(MungedClass.java:424)
      

      Note that /target/classes/config? Shouldn't that be /target/classes?

      Thanks

        Activity

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

        Johann,
        Can you try this with maven-jibx-plugin 1.2.3, jibx-run 1.2.3 and jibx-extras 1.2.3 in the dependencies.
        If you could attach a sample project, it would be very helpful.
        Thanks,
        Don

        Show
        Don Corley added a comment - Johann, Can you try this with maven-jibx-plugin 1.2.3, jibx-run 1.2.3 and jibx-extras 1.2.3 in the dependencies. If you could attach a sample project, it would be very helpful. Thanks, Don
        Hide
        Johann Burkard added a comment -

        Don,

        thanks for your answer.

        Sorry, I can't attach any code since it's my employer's.

        But I tried JiBX 1.2.3, the result was

        org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jibx:maven-jibx-plugin:1.2.3:bind (default) on project XYZ: null
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
        	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
        	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
        	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
        	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
        	at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
        	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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
        Caused by: org.apache.maven.plugin.MojoExecutionException
        	at org.jibx.maven.AbstractBaseBindingMojo.compile(AbstractBaseBindingMojo.java:155)
        	at org.jibx.maven.AbstractBaseBindingMojo.execute(AbstractBaseBindingMojo.java:122)
        	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
        	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
        	... 19 more
        Caused by: java.lang.NullPointerException
        	at org.jibx.binding.classes.MungedClass.checkDirectory(MungedClass.java:238)
        	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:405)
        	at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:443)
        

        I had looked into the code before and I thought the problem was that in ClassFile#writeFile, you never check that the parent directory of m_file actually exists.

        When I patched ClassFile as follows, the problem went away:

            public void writeFile() throws IOException {
                if (m_isModified) {
                	if (!m_file.getParentFile().exists()) {
                		m_file.getParentFile().mkdirs();
                	}
                    OutputStream os = new FileOutputStream(m_file);
                    writeFile(os);
                }
            }
        
        Show
        Johann Burkard added a comment - Don, thanks for your answer. Sorry, I can't attach any code since it's my employer's. But I tried JiBX 1.2.3, the result was org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jibx:maven-jibx-plugin:1.2.3:bind ( default ) on project XYZ: null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException at org.jibx.maven.AbstractBaseBindingMojo.compile(AbstractBaseBindingMojo.java:155) at org.jibx.maven.AbstractBaseBindingMojo.execute(AbstractBaseBindingMojo.java:122) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: java.lang.NullPointerException at org.jibx.binding.classes.MungedClass.checkDirectory(MungedClass.java:238) at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:405) at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:443) I had looked into the code before and I thought the problem was that in ClassFile#writeFile, you never check that the parent directory of m_file actually exists. When I patched ClassFile as follows, the problem went away: public void writeFile() throws IOException { if (m_isModified) { if (!m_file.getParentFile().exists()) { m_file.getParentFile().mkdirs(); } OutputStream os = new FileOutputStream(m_file); writeFile(os); } }
        Hide
        Don Corley added a comment -

        Johann,
        I really need an example of this failure before I can apply your patch.
        I don't need your employer's code, just make a small sample project that only contains this failure.
        To give you an example, here are two bug reports that I filed with another contributor on JiBX:
        http://jira.codehaus.org/browse/JIBX-419
        http://jira.codehaus.org/browse/JIBX-420
        You will notice that the examples that I included in these bug reports are tiny projects with instructions on creating the failure. The actual project that failed is way too complicated to submit as a example.
        I know it takes more time, but I need to be able to replicate the problem before I can fix it.
        Thanks,
        Don

        Show
        Don Corley added a comment - Johann, I really need an example of this failure before I can apply your patch. I don't need your employer's code, just make a small sample project that only contains this failure. To give you an example, here are two bug reports that I filed with another contributor on JiBX: http://jira.codehaus.org/browse/JIBX-419 http://jira.codehaus.org/browse/JIBX-420 You will notice that the examples that I included in these bug reports are tiny projects with instructions on creating the failure. The actual project that failed is way too complicated to submit as a example. I know it takes more time, but I need to be able to replicate the problem before I can fix it. Thanks, Don
        Hide
        Johann Burkard added a comment -

        Don,

        sorry, I will not create an example for three reasons:

        1. No time. I have a lot of personal and professional projects and the last thing I am interested in right now is creating test cases for other people's software bugs, especially if I don't even use their software in the first place and only my employer does.
        2. Creating a file, especially after path manipulation, without creating its parent directory will not work. This is clear from the Apidoc.
        3. I have no idea if I even could reproduce this bug since I have almost zero knowledge of JiBX and anything that starts with "X" isn't very high on my list, either.

        With that said, I found another case of writing to files without having created their parent directories first, this time in MungedClass. This is how I patched the class:

                    File directory = new File
                        (root, pack.replace('.', File.separatorChar));
                    String cpath = directory.getCanonicalPath();
                    if (s_directories.get(cpath) == null) {
                    	File dir = new File(cpath);
                    	if (!dir.exists()) {
                    		dir.mkdirs();
                    	}
                        File[] matches = dir.listFiles(new JiBXFilter());
        

        With these two changes, I could compile the bindings through Maven.

        Show
        Johann Burkard added a comment - Don, sorry, I will not create an example for three reasons: No time. I have a lot of personal and professional projects and the last thing I am interested in right now is creating test cases for other people's software bugs, especially if I don't even use their software in the first place and only my employer does. Creating a file, especially after path manipulation, without creating its parent directory will not work. This is clear from the Apidoc. I have no idea if I even could reproduce this bug since I have almost zero knowledge of JiBX and anything that starts with "X" isn't very high on my list, either. With that said, I found another case of writing to files without having created their parent directories first, this time in MungedClass. This is how I patched the class: File directory = new File (root, pack.replace('.', File.separatorChar)); String cpath = directory.getCanonicalPath(); if (s_directories.get(cpath) == null ) { File dir = new File(cpath); if (!dir.exists()) { dir.mkdirs(); } File[] matches = dir.listFiles( new JiBXFilter()); With these two changes, I could compile the bindings through Maven.
        Hide
        Don Corley added a comment -

        Johann,
        I'm going to reassign this bug to Dennis for now.
        He is the JiBX core project owner and your patches are in his project.
        Perhaps he will be able to recognize the bug that you describe without a test case and apply your patches.
        Sorry,
        Don

        Show
        Don Corley added a comment - Johann, I'm going to reassign this bug to Dennis for now. He is the JiBX core project owner and your patches are in his project. Perhaps he will be able to recognize the bug that you describe without a test case and apply your patches. Sorry, Don
        Don Corley made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Don Corley [ doncorley ] Dennis Sosnoski [ dsosnoski ]
        Resolution Cannot Reproduce [ 5 ]
        Hide
        Vincenz Braun added a comment -

        Please reopen this bug and incorporate the provided bugfix.
        We ran into this problem too and it breaks our sonar build (cobertura step).

        I tried to make a small example to show this problem but without any success.
        We use aspectj and jibx in a multi module build. We see this error when calling
        mvn cobertura:cobertura from the parent module. The submodule alone builds fine.

        Show
        Vincenz Braun added a comment - Please reopen this bug and incorporate the provided bugfix. We ran into this problem too and it breaks our sonar build (cobertura step). I tried to make a small example to show this problem but without any success. We use aspectj and jibx in a multi module build. We see this error when calling mvn cobertura:cobertura from the parent module. The submodule alone builds fine.
        Hide
        Tomas Hudec added a comment - - edited

        .

        Show
        Tomas Hudec added a comment - - edited .

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Johann Burkard
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: