[MNG-6932] NullPointerException if no Package is defined for the current class

[jira-importer]

Bence Sipka opened MNG-6932 and commented

When the maven-resolver and related classes are used with a ClassLoader that doesn't define a java.lang.Package object for the loaded classes, the library throws a NullPointerException.

Scenario: I'm using the maven-resolver classes to resolver artifacts from various repositories. I package the app, and deploy it to a custom environment where the ClassLoader for the app doesn't define a Package for the loaded classes. In these cases, when the maven-resolver library calls this.getClass().getPackage().getImplementationVersion() then a NullPointerException will occurr.

 The following classes are affected:
DefaultSuperPomProvider.getSuperModel():81
DefaultReportingConverter.<init>:56

Code around the locations:

String modelId = "org.apache.maven:maven-model-builder:"
    + this.getClass().getPackage().getImplementationVersion() + ":super-pom";
InputSource inputSource = new InputSource();
inputSource.setModelId( modelId );

This exception makes the library unportable to different environments.

Workaround:

Implement a custom variant of the above classes that circumvent these parts of the code.

Possible solution:

Null checks, and hard coding the version number.

---

Affects: 3.6.3

Issue Links:

• MNG-6593 track input location for super-pom
  ("is caused by")
• MNG-6600 add input location tracking for default lifecycle bindings executions
  ("is caused by")
• MNG-6960 Use RuntimeInformation instead of reading properties
  ("depends upon")

0 votes, 5 watchers

[jira-importer]

Michael Osipov commented

Can you describe how your code does not have packages? Do you use the default package?

[jira-importer]

Bence Sipka commented

The code doesn't have packages in a way, that the ClassLoader that loads the maven-resolves classes, doesn't call ClassLoader.definePackage for the loaded classes. This will result in getClass().getPackage() to return null. Therefore, 
this.getClass().getPackage().getImplementationVersion() will result in a NPE.

According to the documentation of Class.getPackage(), the method can return null, however the implementations in DefaultSuperPomProvider and DefaultReportingConverter doesn't handle this scenario.

I don't use the default packages.

An example for reproducing this:

public static void main(String[] args) throws Exception {
	Path jarpath = Paths.get("maven-resolver-fat-jar.jar");
	try (JarFile jar = new JarFile(jarpath.toFile())) {
		ClassLoader cl = new ClassLoader(null) {
			@Override
			protected Class<?> findClass(String name) throws ClassNotFoundException {
				ZipEntry entry = jar.getEntry(name.replace('.', '/') + ".class");
				if (entry != null) {
					try (InputStream is = jar.getInputStream(entry)) {
						ByteArrayOutputStream baos = new ByteArrayOutputStream();
						byte[] buf = new byte[4096];
						for (int read; (read = is.read(buf)) > 0;) {
							baos.write(buf, 0, read);
						}
						byte[] classbytes = baos.toByteArray();
						return defineClass(name, classbytes, 0, classbytes.length);
					} catch (IOException e) {
					}
				}
				return super.findClass(name);
			}
		};
		Class<?> defaultreportinconverterclass = cl.loadClass("org.apache.maven.model.plugin.DefaultReportingConverter");
		System.out.println("App.main() " + defaultreportinconverterclass);
		System.out.println("App.main() " + defaultreportinconverterclass.getPackage());
		defaultreportinconverterclass.getConstructor().newInstance();
	}
}

Minimal example for loading an affected class via a custom classloader from a fat JAR. The maven-resolver-fat-jar.jar contains all classes required by the maven-resolver to operate.

The anonymous ClassLoader inner class loads the classes from the appropriate JAR entries.

The program will produce the following output:

App.main() class org.apache.maven.model.plugin.DefaultReportingConverter
App.main() null
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at example.saker.maven.support.App.main(App.java:191)
Caused by: java.lang.NullPointerException
	at org.apache.maven.model.plugin.DefaultReportingConverter.<init>(DefaultReportingConverter.java:56)
	... 5 more

As you can see, a NullPointerException occurs when the DefaultReportingConverter class is being instantiated, as it will call this.getClass().getPackage().getImplementationVersion(). But due to the fact, that no definePackage is called by the ClassLoader, it throws a NPE.

The same kind of error occurs when using DefaultSuperPomProvider.

[jira-importer]

Michael Osipov commented

OK, thanks I will look into this. What is your recommendation to fix this issue?

[jira-importer]

Bence Sipka commented

Disclaimer: I'm not very vell versed in the implementation details of the maven-resolver library.

In my opinion, replacing the this.getClass().getPackage().getImplementationVersion() call with a hard coded value may work, however, it needs to be updated for every release.

String modelId = "org.apache.maven:maven-model-builder:" + "3.6.2" + ":super-pom";

 Based on debugging, currently the 3.6.2 string is used under normal circumstances. This would need to be inserted in both DefaultReportingConverter initialization block, and DefaultSuperPomProvider.getSuperModel() function.

I recommend to export the "3.6.2" constant to some utility class that holds this constant, and that can be updated easily in one place.

However, I'm not sure what is the purpose of including the version number in that modelId, therefore the following could also work:

Check if the Package is null.

Package pack = this.getClass().getPackage();
String modelId = "org.apache.maven:maven-model-builder:" + (pack == null ? "null" : pack.getImplementationVersion()) + ":super-pom";

 Modify DefaultReportingConverter accordingly as well.

The null-check modification is compatible with previous implementations, as it only results in avoiding the NPE, and doesn't result in other side effects.

The hard-coded version modification will induce the maintenance burden of updating the version number for the newer releases.

[jira-importer]

Michael Osipov commented

The version could likely be solved by reading the pom.properties whereas the package could be static. It would change anyway, will it?

[jira-importer]

Bence Sipka commented

I'm not entirely sure what you mean, but as far as I understand, yes. Reading the pom.properties file would be appropriate for solving this issue. In this case, retrieving the Package object for the class will be unnecessary.

The META-INF/maven/org.apache.maven/maven-model-builder/pom.properties contains the property version with the value 3.6.2. Using it in both of the mentioned cases would be suitable.

[jira-importer]

Michael Osipov commented

So this requires changes in Maven Core. There are three spots using #getPackage() w/o a null check.

[jira-importer]

Michael Osipov commented

Robert Scholte, can you have a look at MRESOLVER-94 in Maven Core repo. This is a way to fix this. The other affected classes are in Maven Model Builder which don't have access to RuntimeInformation. I'd duplicate (sigh) the code into Maven Builder Support and load from there if no Package instance is available. WDYT?

[jira-importer]

Robert Scholte commented

Current solutions depend on the MANIFEST.MF or pom.properties, both generated during packaging, which is a sign it is actually too late.
We could use the template-maven-plugin, but that might not work good within the IDE.
I think it should be possible to add a processor to the compiler to set a value of some (annotated) field.
Haven't done this before, though, but it should remove any other hack, because the correct value is applied during compilation.

[jira-importer]

Michael Osipov commented

This sounds promising, but how does one pass the ${project.version} to the processor?

[jira-importer]

Robert Scholte commented

Somebody needs to figure that out, but probably a system property (isolated for the compiler).

[jira-importer]

Michael Osipov commented

As far as I understand this you cannot modify anything. I will with pom.properties for now. The annotation processor is beyond my knowledge and time.

[jira-importer]

Michael Osipov commented

Bence Sipka, do you want to pick up my branch and continue to work on it? This will resolve your problem.

[jira-importer]

Hervé Boutemy commented

Do you see any benefit in having the Maven version in the identifier?
yes, there is a benefit: given version of the plugin depends on Maven core version (in the future, even more than in the past), yes, showing which version of Maven core injected the plugin version is useful

[jira-importer]

Michael Osipov commented

OK, granted. So instead of using the manifest data, using RuntimeInformation seems right for me. But for this, we need to remove the static final variable and move it to a method on the interface. WDYT?