[
https://issues.apache.org/jira/browse/SLING-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-830:
------------------------------------
Description:
When doing a full build of Sling from the root of the trunk using the Maven
Reactor, the final launchpad/app JAR file cannot be started because a JAR is
said to not be verifiable (see also [1]):
sling/launchpad/app/target# java -jar
org.apache.sling.launchpad.app-5-incubator-SNAPSHOT.jar -c sling -f -
Exception in thread "main" java.lang.SecurityException: Invalid signature file
digest for Manifest main attributes
at
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
at
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:277)
at java.util.jar.JarVerifier.update(JarVerifier.java:188)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:321)
at java.util.jar.JarFile.getInputStream(JarFile.java:386)
at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:689)
at sun.misc.Resource.cachedInputStream(Resource.java:59)
at sun.misc.Resource.getByteBuffer(Resource.java:154)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: org.apache.sling.launcher.app.main.Main. Program
will exit.
It seems that on a full build, the signature files from the Eclipse HttpService
Bridge are included, which cause the JAR class loader to try to verify the jar
file, which of course fails. The files are META-INF/ECLIPSE.SF and
META-INF/ECLIPSE.RSA. If these files are not in the final JAR, it starts up
flawlessly.
When doing a single-module build of the the launchpad/base first and then
launchpad/app, the JAR file is correctly created without these Eclipse
signature files. So it looks like this problem is related to the reactor build.
In addition, the launchpad/base build is defined to ignore the META-INF folders
of the included libraries. This does not seem to be obeyed in the reactor build
case.
So, I assume this is related to the maven-dependency-plugin being used to glue
the launchpad/base library together is not the correct version, since multiple
versions are used throughout the build process and there is no managed version
number in the parent pom.
Adding the maven-dependency-plugin to the parent pom's pluginManagement with
version 2.0 and removing all explicit version references actually fixes this
problem and the resulting jar starts correctly, even after a reactor build.
[1] http://markmail.org/message/4fxvcvm4jhiveb7l
was:
When doing a full build of Sling from the root of the trunk using the Maven
Reactor, the final launchpad/app JAR file cannot be started because a JAR is
said to not be verifiable (see also [1]):
sling/launchpad/app/target# java -jar
org.apache.sling.launchpad.app-5-incubator-SNAPSHOT.jar -c sling -f -
Exception in thread "main" java.lang.SecurityException: Invalid signature file
digest for Manifest main attributes
at
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
at
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:277)
at java.util.jar.JarVerifier.update(JarVerifier.java:188)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:321)
at java.util.jar.JarFile.getInputStream(JarFile.java:386)
at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:689)
at sun.misc.Resource.cachedInputStream(Resource.java:59)
at sun.misc.Resource.getByteBuffer(Resource.java:154)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: org.apache.sling.launcher.app.main.Main. Program
will exit.
It seems that on a full build, the signature files from the Eclipse HttpService
Bridge are included, which cause the JAR class loader to try to verify the jar
file, which of course fails. The files are META-INF/ECLIPSE.SF and
META-INF/ECLIPSE.RSA. If these files are not in the final JAR, it starts up
flawlessly.
When doing a single-module build of the the launchpad/base first and then
launchpad/app, the JAR file is correctly created without these Eclipse
signature files. So it looks like this problem is related to the reactor build.
In addition, the launchpad/base build is defined to ignore the META-INF folders
of the included libraries. This does not seem to be obeyed in the reactor build
case.
So, I assume this is related to the maven-dependency-plugin being used to glue
the launchpad/base library together is not the correct version, since multiple
versions are used throughout the build process and there is no managed version
number in the parent pom.
Adding the maven-dependency-plugin to the parent pom's pluginManagement with
version 2.0 and removing all explicit version references actually fixes this
problem and the resulting jar starts correctly, even after a reactor build.
> Startup failure when after a full build of Sling.
> -------------------------------------------------
>
> Key: SLING-830
> URL: https://issues.apache.org/jira/browse/SLING-830
> Project: Sling
> Issue Type: Bug
> Components: General
> Affects Versions: Launchpad Base 2.0.4, Launchpad App 4, Launchpad Webapp 4
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Priority: Critical
> Fix For: Launchpad Base 2.0.4, Launchpad App 4, Launchpad Webapp 4
>
>
> When doing a full build of Sling from the root of the trunk using the Maven
> Reactor, the final launchpad/app JAR file cannot be started because a JAR is
> said to not be verifiable (see also [1]):
> sling/launchpad/app/target# java -jar
> org.apache.sling.launchpad.app-5-incubator-SNAPSHOT.jar -c sling -f -
> Exception in thread "main" java.lang.SecurityException: Invalid signature
> file digest for Manifest main attributes
> at
> sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
> at
> sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
> at java.util.jar.JarVerifier.processEntry(JarVerifier.java:277)
> at java.util.jar.JarVerifier.update(JarVerifier.java:188)
> at java.util.jar.JarFile.initializeVerifier(JarFile.java:321)
> at java.util.jar.JarFile.getInputStream(JarFile.java:386)
> at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:689)
> at sun.misc.Resource.cachedInputStream(Resource.java:59)
> at sun.misc.Resource.getByteBuffer(Resource.java:154)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> Could not find the main class: org.apache.sling.launcher.app.main.Main.
> Program will exit.
> It seems that on a full build, the signature files from the Eclipse
> HttpService Bridge are included, which cause the JAR class loader to try to
> verify the jar file, which of course fails. The files are META-INF/ECLIPSE.SF
> and META-INF/ECLIPSE.RSA. If these files are not in the final JAR, it starts
> up flawlessly.
> When doing a single-module build of the the launchpad/base first and then
> launchpad/app, the JAR file is correctly created without these Eclipse
> signature files. So it looks like this problem is related to the reactor
> build. In addition, the launchpad/base build is defined to ignore the
> META-INF folders of the included libraries. This does not seem to be obeyed
> in the reactor build case.
> So, I assume this is related to the maven-dependency-plugin being used to
> glue the launchpad/base library together is not the correct version, since
> multiple versions are used throughout the build process and there is no
> managed version number in the parent pom.
> Adding the maven-dependency-plugin to the parent pom's pluginManagement with
> version 2.0 and removing all explicit version references actually fixes this
> problem and the resulting jar starts correctly, even after a reactor build.
> [1] http://markmail.org/message/4fxvcvm4jhiveb7l
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
