Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

The way the container classpath is managed in all JBoss 7.x containers and all WildFly containers is slightly different from most others.

How the container classpath is added to the JBoss / WildFly container

In order to add the container classpath to the JBoss / WildFly container, CARGO takes the below steps:

  1. The JAR files which are in the container classpath are copied in the modules/org/codehaus/cargo/classpath subdirectory of the container home
    Attention: The JAR files are copied in the container home, and not into the configuration home. Hence, the JBoss / WildFly container's binaries are actually modified ad vidam eternam (until you manually clean it up).
  2. For each JAR file, a module.xml file is created with the below rule for dependencies:
    1. The first JAR file has dependencies javax.api and javax.transaction.api
    2. The second JAR has dependencies javax.api, javax.transaction.api and the first JAR
      ... and so on

Modification in the applications

During deployment, CARGO will edit your deployables' META-INF/MANIFEST.MF file in order to add the property Dependencies with all the JARs in the container classpath.

As per the logic followed to add these into the JBoss / WildFly container's classpath, these dependencies all start with the prefix org.codehaus.cargo.classpath.

  • No labels