You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/01/15 15:20:59 UTC

[jira] Resolved: (SLING-830) Startup failure when after a full build of Sling.

     [ https://issues.apache.org/jira/browse/SLING-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger resolved SLING-830.
-------------------------------------

    Resolution: Fixed

After fixing these plugin versions, my build runs smoothly and the launcher jar starts as well.

Waiting for some feedback from the list before closing this issue.

> 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.