Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
nifi-nar-maven-plugin-1.3.1
-
None
-
None
Description
org.apache.maven.plugin.MojoExecutionException: Failed to create Extension Documentation at org.apache.nifi.NarMojo.generateDocumentation (NarMojo.java:596) at org.apache.nifi.NarMojo.execute (NarMojo.java:499) ... Caused by: java.lang.UnsatisfiedLinkError: no [Library] in java.library.path at java.lang.ClassLoader.loadLibrary (ClassLoader.java:1867) at java.lang.Runtime.loadLibrary0 (Runtime.java:870) at java.lang.System.loadLibrary (System.java:1122) ... at org.apache.nifi.processor.AbstractSessionFactoryProcessor.initialize (AbstractSessionFactoryProcessor.java:63) at org.apache.nifi.documentation.AbstractDocumentationWriter.initialize (AbstractDocumentationWriter.java:86)
Custom processors that require native libraries for the implementation fail to generate documentation during nar build due to the need to initialize the processor.
While this could be resolved by a command line update to the java.library.path, I think that it would be better to extend the ExtensionClassLoader to attempt to find the libraries (similar to as done by the NarClassLoader.
My current temporary solution which uses a customized nifi-nar-maven-plugin is to add the following function to the ExtensionClassLoader:
protected String findLibrary(final String libname) { final File nativeDir = new File(projectOutputDirectory/*from MavenProject*/, "META-INF/bundled-dependencies/native"); final File libsoFile = new File(nativeDir, "lib" + libname + ".so"); final File dllFile = new File(nativeDir, libname + ".dll"); final File soFile = new File(nativeDir, libname + ".so"); if (libsoFile.exists()) return libsoFile.getAbsolutePath(); else if (dllFile.exists()) return dllFile.getAbsolutePath(); else if (soFile.exists()) return soFile.getAbsolutePath(); return null; }