JiBX

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Hide
Permalink
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
Permalink
Tomas Hudec added a comment - - edited

.

Show
Tomas Hudec added a comment - - edited .

People

  • Assignee:
    Dennis Sosnoski
    Reporter:
    Johann Burkard
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: