I've constructed a war that looks something like below

foo.war
|-- Capsule.class
`-- WEB-INF
     |-- lib
     `-- classes
          |-- logging.properties
          `-- package/with/classes/SomeClass.class

Looking at the cache directory after running the application WEB-INF/classes only contans logging.properties and neither the directory structure nor classes within.

capsule-0.7.1 / Windows 8.

ctrl-c on Linux gracefully terminates both JVMs and my app. ctrl-c on Windows CMD prompt terminates both JVMs but not gracefully AFAICS.

My app has a JVM shutdown hook that produces many log lines. Intermittently I see the first log entry so perhaps Capsule shutdown is too aggressive? My app might be shutting down gracefully but silently, not sure.

As a lesser issue, ctrl-c on Windows Babun/zsh/Cygwin terminates the Capsule JVM but leaves the app JVM orphaned & running.

I'we made a thin jar using the maven plugin, and try to run it. During the download dependancies phase, I get error messages like these for a few dependencies:

CAPSULE: Downloading: file:/Users/viktor/.m2/repository/com/thoughtworks/xstream/xstream/1.4.2/xstream-1.4.2.jar
CAPSULE: Downloaded: file:/Users/viktor/.m2/repository/com/thoughtworks/xstream/xstream/1.4.2/xstream-1.4.2.jar (471 KB at 530.3 KB/sec)
CAPSULE: Downloading: file:/Users/viktor/.m2/repository/org/hibernate/hibernate-core/3.3.2.GA/hibernate-core-3.3.2.GA.jar
CAPSULE: Transfer failed: capsule.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.hibernate:hibernate-core:jar:3.3.2.GA in local (file:/Users/viktor/.m2/repository)
capsule.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.hibernate:hibernate-core:jar:3.3.2.GA in local (file:/Users/viktor/.m2/repository)
    at capsule.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
    at capsule.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
    at capsule.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:744)
CAPSULE: Downloading: file:/Users/viktor/.m2/repository/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar
CAPSULE: Downloaded: file:/Users/viktor/.m2/repository/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar (629 KB at 707.9 KB/sec)

Then, at run time, I (predictably) get "methodNotFound" errors:

Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.validator.HibernateValidatorConfiguration.addValidatedValueHandler(Lorg/hibernate/validator/spi/valuehandling/ValidatedValueUnwrapper;)Lorg/hibernate/validator/HibernateValidatorConfiguration;
    at io.dropwizard.setup.Bootstrap.<init>(Bootstrap.java:66)
    at io.dropwizard.Application.run(Application.java:67)
    at com.videoplaza.forecast.webservice.ForecastApiApplication.main(ForecastApiApplication.java:25)

It's probably unwise to keep going after a dependancy has failed to resolve.. Also I would like to hide a bit of the capsule output as it is hard to pick up what is my application, what is capsule, and what went wrong right now.

As for the actual error, I would appreciate any help on that too, obviously :p The local repository does indeed not contain the jar it's looking for, only a POM. I would assume the right thing to do in that case would be to check maven central too.. Or perhaps, for some reason, some dependancy only wants to see the POM but doesn't need the jar? I have no idea actually.

This is the message I get when starting up:

CAPSULE: Dependency manager initialized with repositories: [central, (central,, default, releases+snapshots), local (file:/Users/viktor/.m2/repository, default, releases+snapshots)]

And my build step:

<!-- BUILD CAPSULES -->
      <plugin>
         <groupId>com.github.christokios</groupId>
         <artifactId>capsule-maven-plugin</artifactId>
         <version>0.8.0-SNAPSHOT</version>
         <executions>
            <execution>
               <phase>package</phase>
               <goals>
                  <goal>capsule</goal>
               </goals>
               <configuration>

                  <!-- REQUIRED -->
                  <appClass>com.videoplaza.forecast.webservice.ForecastApiApplication</appClass>

                  <!-- OPTIONAL -->
                  <outputDir>target/</outputDir>
                  <!--<properties>-->
                     <!--<property>-->
                        <!--<name>propertyName1</name>-->
                        <!--<value>propertyValue1</value>-->
                     <!--</property>-->
                  <!--</properties>-->
                  <buildExec>true</buildExec>
                  <manifest>
                     <!--<property>-->
                        <!--<name>JVM-Args</name>-->
                        <!--<value>-Xmx512m</value>-->
                     <!--</property>-->
                     <property>
                        <name>Repositories</name>
                        <value>central, local</value>
                     </property>
                     <property>
                        <name>Allow-Snapshots</name>
                        <value>true</value>
                     </property>
                     <property>
                        <name>Min-Java-Version</name>
                        <value>1.8.0</value>
                     </property>
                  </manifest>

               </configuration>
            </execution>
         </executions>
      </plugin>

Thankful for your help!

I understand that the cache dir is configurable by env or system parameters and that the default location is the within a user's home directory. What I'd like is the option to set the default cache location to be co-located with the Capsule.

/mycapsule.jar
/lib/{extract/download dependencies here}

It would be rather convenient to set something in the Capsule at build time that preferred this extraction point rather than relying on users to set an environment variable or providing a wrapper script.

Let me begin by saying that capsule is a great tool, that has many amazing features to streamline java app deployment and startup!

My setup is the following:

• JRE 1.7.0_25-b15
• Using Gradle Capsule Plugin to build a fat jar

The gradle task looks like:

task fatCapsule(type:FatCapsule) {
  applicationClass '######'
  capsuleManifest {
    environmentVariables = [
      'CAPSULE_CACHE_DIR': '######'
    ]
  }
}

The output capsule manifest looks like:

Manifest-Version: 1.0
Main-Class: Capsule
Application-Class: #######
Environment-Variables: CAPSULE_CACHE_DIR=#######

I am working with capsule in a production system, in which it is not possible to write into the process' user home dir. I have tried the following approaches:

• Set Extract-Capsule to false in the capsule manifest. I have verified that capsule no longer writes all the jars to the cache; however, capsule still creates the dir, which is undesirable. Also, when executing the capsule jar, there's an error that the capsule can't be found.
• Set the 'Environment-Variables' manifest property to update the CAPSULE_CACHE_DIR. When I looked at the output of ps -ef | grep capsule, the second jvm process spawned is still using the default home dir setting.
• Make a bash wrapper for my capsule-jar that will manually set the CAPSULE_CACHE_DIR, if it's not set, to avoid deployment overhead. This works; however, I would like to have this without a bash wrapper, for users that will interact with the capsule jar directly.

When extending the application CLASSPATH (overriding the attribute method and using the ATTR_APP_CLASS_PATH attribute) any directory path is automatically suffixed with a .jar extension by Capsule.

This does not allow custom folders to be added to an application CLASSPATH.

Based off the conversation from #47, I decided to go with the approach of caching to /tmp; however, in that scenario, users would be sharing the same cache. I noticed that capsule keeps a .lock file, which is world-readable but not world-writable (obviously; just stating the case for completeness). The user who first generates the cache will be both user and group for the entire cache, including the .lock file; however, I noticed that the .lock file was not cleaned up after running the app via capsule.

It looks like all of the files under the main cache dir are world-readable (without umask interfering, of course), so as long as capsule only does reads against the cache, there should not be a problem with the fact that the user/group are both the set to the user who first generated the cache. However, it appears there may be issues in capsule with keeping this .lock file in-sync when the cache is in a shared location.

The main error we are getting for other users is the typical AccessDeniedException when trying to access the .lock file:

CAPSULE EXCEPTION: java.nio.file.AccessDeniedException: /path/to/cache/apps/X/.lock (for stack trace, run with -Dcapsule.log=verbose)

I can run with verbose on, if you think it would add additional info.

Hi @pron , I currently use capsule to build a executable application jar which embeded web server. When I close application, the exception randomizedly occurred, the message as follow:

2016-01-23 19:50:14,384 [Thread-1] INFO  c.github.dolphineor.web.WebAppServer - Undertow web server on port 8081 stopped
CAPSULE EXCEPTION: nullCAPSULE: Exception on thread cleanup: null
CAPSULE EXCEPTION: null while processing null null: null while processing null null: null (for stack trace, run with -Dcapsule.log=verbose)
 (for stack trace, run with -Dcapsule.log=verbose)
Exception in thread "cleanup" java.util.ConcurrentModificationException
        at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
        at java.util.ArrayList$Itr.next(Unknown Source)
        at Capsule.cleanup0(Capsule.java:1417)
        at Capsule.cleanup(Capsule.java:1403)
        at Capsule.cleanup1(Capsule.java:1390)
        at Capsule.run(Capsule.java:1309)
        at java.lang.Thread.run(Unknown Source)

Is there something wrong with me? Thanks in advance.

Getting this error after upgrading Capsule to version 0.10.0:

CAPSULE: Launching app example.FooBarService_0.0.1
CAPSULE: Locking /home/example/.capsule/apps/example.FooBarService_0.0.1/.lock
CAPSULE: Extracting /usr/share/example-service/lib/example-service.jar to app cache directory /home/example/.capsule/apps/example.FooBarService_0.0.1
CAPSULE: Error parsing Java version 1.8.0_31
CAPSULE: Unocking /home/example/.capsule/apps/example.FooBarService_0.0.1/.lock
CAPSULE EXCEPTION: null while processing system property java.home: /usr/lib/jvm/java-8-oracle/jre
java.lang.NullPointerException
    at Capsule.getJavaHomes(Capsule.java:2998)
    at Capsule.findJavaHome(Capsule.java:2125)
    at Capsule.chooseJavaHome0(Capsule.java:2107)
    at Capsule.chooseJavaHome(Capsule.java:2098)
    at Capsule.getJavaHome(Capsule.java:2085)
    at Capsule.getJavaExecutable0(Capsule.java:1633)
    at Capsule.getJavaExecutable(Capsule.java:1625)
    at Capsule.buildJavaProcess(Capsule.java:1579)
    at Capsule.buildProcess0(Capsule.java:1153)
    at Capsule.buildProcess(Capsule.java:1144)
    at Capsule.prelaunch0(Capsule.java:1122)
    at Capsule.prelaunch(Capsule.java:1118)
    at Capsule.prepareForLaunch(Capsule.java:1033)
    at Capsule.launch(Capsule.java:974)
    at Capsule.main0(Capsule.java:296)
    at Capsule.main(Capsule.java:275)

JAVA_HOME is set:

$ echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle

Here's the MANIFEST.MF for this application:

Manifest-Version: 1.0
Main-Class: Capsule
Application-Class: example.FooBarService
Application-Version: 0.0.1
Min-Java-Version: 1.8
JVM-Args:
System-Properties: example.config=/etc/example-service/example.yml

I successfully generated and ran a "fat" (fully contained) Capsule.

I am now trying to distribute it as a launch4j executable.

I then get the following error at run time: CAPSULE EXCEPTION: Not a JAR/ZIP file while processing environment variable LOCALAPPDATA: C:\Users\Olivier\AppData\Local (for stack trace, run with -Dcapsule.log=verbose)

Considering that one of launch4j selling point is "Doesn't extract the jar from the executable", can a Capsule work in this environment?

Regards.

Hi Ron,

there are a couple of functions especially useful for Capsule plugin writers (egoistically speaking, https://github.com/circlespainter/lein-capsule, in my case especially helpful together with this https://github.com/cemerick/pomegranate/pull/69) I'd like to expose as public but they're part of a build-time Capsule API, which doesn't seem to exist yet (as far as I have seen).

In order to reuse some information from the main capsule module I did some refactoring there too (mainly exposing constants in DependenciesManager but also some stdlib-level Java utilities).

Do you think this could be merged or do you have any suggestions to improve it (or about other approaches)?

TIA! - Fabio

For example, if we set the JAVA_TOOL_OPTIONS environment variable

export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8

then the first line is not the version:

$ java -version                                
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-macos-aarch64) (build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Zulu 8.60.0.21-CA-macos-aarch64) (build 25.322-b06, mixed mode)

The getActualJavaVersion looks only at the first line (see here).

Ideally, it would skip over leading lines that start with Picked up. Related to https://github.com/nextflow-io/nextflow/issues/1716

Hello,

capsule is packaged in Debian, where we are currently checking if building packages is still possible with OpenJDK 17, whereas we currently use OpenJDK 11. Hence the bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011924 concerning capsule. The current pull request solves the issue in the bug, but then I get 40 failing tests, please see the enclosed log. failingTests_openJDK17_20220529.txt

I guess there are various reasons why the tests fail, for instance testWrapperCapsuleAgent certainly fails because of the illegal reflective access attempt in CapsuleTestUtils.accessible (which "only" issued a warning with previous JDKs). For other tests, I admit I have not gone into details that much.

I will be happy to provide you with more details if I can and I would appreciate any help to achieve OpenJDK 17 compatibility if you have time for it,

Best, Pierre

The current regex fails to parse 11.0.9.1-internal due to the .1 "update" group. This version is coming from openjdk conda forge. See here for more details.

This change allows for _<update> or .<update> in the version string.

The capsule docs web site is not more accessible. http://www.capsule.io/

Is there are any chance to restore it or to have access to any other copy of the docs?

Hi all, Our bug scanner has reported some NPE bugs.

1.The first bug is at Jar.java#L459 . Since the variable zis may be null , a NPE bug may take place when zis invokes its method getNextEntry() .

2.The second bug is at Capsule.java#L1715 . Since the variable server may be null , a NPE bug may take place when server invokes its method setSoTimeout() .

A similar situation is at Capsule.java#L5362 . (The variable out may be null.)

3.The third bug is at Capsule.java#L1229 . Since the variable defaultValue is checked for whether being null or not at Capsule.java#L1231 , a NPE bug may take place when defaultValue invokes its method equals() at Capsule.java#L1229 .

4.The forth bug is at Capsule.java#L3341 . Since the variable type is checked for whether being null or not at Capsule.java#L3351 , a NPE bug may take place when defaultValue invokes its method equals() at Capsule.java#L3341 .

5.The fifth bug is caused by the return null in method getAfter() . A NPE bug may take place when the return value of method getAfter() invokes its method substring() .

6.The sixth bug is caused by the return value of the method getAttribute0(). Since the if statement block may be skipped, the method getAttribute0() may return null. A possible call chain is attribute00() => attribute0() =>getAttribute() =>isDependency() . A NPE bug may take place in isDependency() when the parameter lib invokes its method contains() .

Some other NPE bugs are at Capsule.java#L2451 , Capsule.java#L843 , Capsule.java#L4001 , Capsule.java#L2514(when the method size() is invoked) .

7.The seventh bug is caused by the return null in method accessible() . A NPE may take place when the return value of method accessible() invokes its method set().

Some similar situations are at Capsule.java#L5637 , Capsule.java#L5476-5477 , Capsule.java#L5601 , Capsule.java#L5620

Another possible call chain is Capsule.java#L4835 =>Capsule.java#L4826 =>Capsule.java#L608 . And a NPE bug may take place when the method getDeclaringClass() is invoked.

The third possible call chain is Capsule.java#L4835 =>Capsule.java#L1311 . A NPE bug may take place when the method invoke() is invoked.

8.The eighth bug is caused by the return null in method toAbsolutePath() . A possible call chain is Capsule.java#L2067 =>Capsule.java#L2073 . And a NPE bug may take place in method extractCapsule() when the parameter dir invokes its method toAbsolutePath().

Another possible call chain is Capsule.java#L2067=>Capsule.java#L2070=>Capsule.java#L2104 . And a NPE bug may take place in method lockAppCache() when the parameter dir invokes its method resolve().

The third possible call chain is Capsule.java#L2067=>Capsule.java#L2070=>Capsule.java#L2105 . And a NPE bug may take place in method testAppCacheUpToDate() when the parameter dir invokes its method resolve().

Similar situations are at Capsule.java#L2072 => Capsule.java#L2088 , Capsule.java#L2070 => Capsule.java#L2107 => Capsule.java#L2173 .

9.The ninth bug is caused by the return null in method resolve() . A possible call chain is Capsule.java#L2228=>Capsule.java#L2234. And a NPE bug may take place in method handleLongClasspath() when the parameter cp invokes its method size().

Another call chain is Capsule.java#L2223=>Capsule.java#L2285=>Capsule.java#L4704 . A NPE bug may take place when the method iterator() is invoked.

10.The tenth bug is caused by the return null in method firstOrNull() . A NPE bug may take place at Capsule.java#L3542 when the method toString() of the parameter p is invoked.

11.The eleventh bug is caused by the return null in method name() . It may cause a NPE bug when the equals() method is invoked.

12.The twelfth bug is caused by the return null in method getCacheDir() . It may cause a NPE bug when the resolve() method is invoked.

13.The thirteenth bug is caused by the return null in method getProperty0() . A possible call chain is getProperty() =>Capsule.java#L218 . A NPE bug may take place when the method toLowerCase() is invoked.

14.The fourteenth bug is caused by the return null in method shortJavaVersion() . A NPE bug may take place when the method split() is invoked.

15.The fifteenth bug is caused by the return null in method lookupInAttribute() . A possible call chain is Capsule.java#L3181 => Capsule.java#L2735 => Capsule.java#L1492 . A NPE bug may take place when the booleanValue() method is invoked at Capsule.java#L1492.

16.The sixteenth bug is caused by the return null in method simpleResolve() . A possible call chain is Capsule.java#L3525 => Capsule.java#L3533 . A NPE bug may take place when the getParent() method is invoked .

17.The seventeenth bug is caused by the return null in method split() . A possible call chain is Capsule.java#L2445 => Capsule.java#L2446 . A NPE bug may take place when the remove() method is invoked .

18.The eighteenth bug is caused by the return null in method getTempDir() . A possible call chain is Capsule.java#L5290 . A NPE bug may take place in method createPathingJar() when the toAbsolutePath() method is invoked since the parameter dir may be null.

19.The nineteenth bug is caused by the return null in method getAppArtifactId() . A possible call chain is Capsule.java#L2655 =>Capsule.java#L2881 =>MyCapsule.java#L42 . And a NPE bug may take place when the method listIterator() is invoked.

20.The twentyth bug is caused by the return null in method getAppArtifactId() . A possible call chain is Capsule.java#L2672 =>Capsule.java#L2881 =>MyCapsule.java#L36 . And a NPE bug may take place when the method put() is invoked.

Thanks.