News
Analyzed 6 days
ago based on code collected 7 days ago.
|
Posted
3 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen This page has been automatically generated by Cargo's build. Do not edit it directly as it'll be overwritten next time it's generated ... [More] again. Container FeaturesFeature name Java Ant Maven2 Comment Container Instantiation ContainerFactory.createContainer("jetty7x"...) <cargo containerId="jetty7x".../> <containerId>jetty7x</containerId> Local Container Container Classpath Container Start Container Stop Container Timeout Embedded Container o.c.c.c.jetty.Jetty7xEmbeddedLocalContainer Installed Container o.c.c.c.jetty.Jetty7xInstalledLocalContainer Passing system properties Installer Remote Container o.c.c.c.jetty.Jetty7xRemoteContainer Configuration FeaturesFeature name Java Ant Maven2 Comment Standalone Local Configuration for installed container o.c.c.c.jetty.Jetty7xStandaloneLocalConfiguration Standalone Local Configuration for embedded container o.c.c.c.jetty.Jetty7xEmbeddedStandaloneLocalConfiguration Existing Local Configuration for installed container o.c.c.c.jetty.Jetty7xExistingLocalConfiguration Existing Local Configuration for embedded container Runtime Configuration o.c.c.c.jetty.JettyRuntimeConfiguration Static deployment of WAR Static deployment of expanded WAR Static deployment of EJB Static deployment of EAR Static deployment of RAR Static deployment of files Static deployment of OSGi Bundles Deployer FeaturesFeature name Java Ant Maven2 Comment Installed Deployer o.c.c.c.jetty.Jetty7xInstalledLocalDeployer Embedded Deployer o.c.c.c.jetty.Jetty7xEmbeddedLocalDeployer Remote Deployer o.c.c.c.jetty.JettyRemoteDeployer Other FeaturesFeature name Java Ant Maven2 Comment Debugging Supported Configuration propertiesThe tables below list both the general configuration properties as well as the container-specific ones. Standalone Local Configuration PropertiesFor installed container o.c.c.c.jetty.Jetty7xInstalledLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 5 or newer cargo.jetty.createContextXml JettyPropertySet.CREATE_CONTEXT_XML true cargo.jetty.servlet.default.useFileMappedBuffer JettyPropertySet.USE_FILE_MAPPED_BUFFER true cargo.jetty.session.path JettyPropertySet.SESSION_PATH N/A cargo.jvmargs GeneralPropertySet.JVMARGS N/A cargo.logging GeneralPropertySet.LOGGING medium cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.process.spawn GeneralPropertySet.SPAWN_PROCESS false cargo.protocol GeneralPropertySet.PROTOCOL http cargo.runtime.args GeneralPropertySet.RUNTIME_ARGS N/A cargo.servlet.port ServletPropertySet.PORT 8080 cargo.servlet.users ServletPropertySet.USERS N/A cargo.standalone.ignoreNonExistingProperties GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES false Datasource and Resource configuration In addition to the forementioned properties, this container configuration can also set up datasources and/or resources. For more details, please read: DataSource and Resource Support. For embedded container o.c.c.c.jetty.Jetty7xEmbeddedLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 5 or newer cargo.jetty.createContextXml JettyPropertySet.CREATE_CONTEXT_XML true cargo.jetty.servlet.default.useFileMappedBuffer JettyPropertySet.USE_FILE_MAPPED_BUFFER true cargo.jetty.session.path JettyPropertySet.SESSION_PATH N/A cargo.jvmargs GeneralPropertySet.JVMARGS N/A cargo.logging GeneralPropertySet.LOGGING medium cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.protocol GeneralPropertySet.PROTOCOL http cargo.runtime.args GeneralPropertySet.RUNTIME_ARGS N/A cargo.servlet.port ServletPropertySet.PORT 8080 cargo.servlet.users ServletPropertySet.USERS N/A cargo.standalone.ignoreNonExistingProperties GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES false Existing Local Configuration PropertiesFor installed container o.c.c.c.jetty.Jetty7xInstalledLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 5 or newer cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.process.spawn GeneralPropertySet.SPAWN_PROCESS false cargo.protocol GeneralPropertySet.PROTOCOL http cargo.servlet.port ServletPropertySet.PORT 8080 If you specify cargo.runtime.args with --ini=anyfile.ini (where anyfile.ini points to a Jetty INI file), any property set in the CARGO Jetty container will be ignored and the ones read from the INI file used instead. Runtime Configuration PropertiesBefore using the Jetty remote deployer, please read: Jetty Remote Deployer For remote container o.c.c.c.jetty.Jetty7xRemoteContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.remote.password RemotePropertySet.PASSWORD N/A cargo.remote.username RemotePropertySet.USERNAME N/A cargo.servlet.port ServletPropertySet.PORT 8080 Tested OnThis container is automatically tested on its server using the Codehaus Cargo Continous Integration System once a day. The server used for tests is downloaded from: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/7.6.11.v20130520/jetty-distribution-7.6.11.v20130520.tar.gzLink to the build plan: https://bamboo-ci.codehaus.org/browse/CARGO-SAMPLESJETTY7X View Online · View Changes Online [Less] |
||||||
|
Posted
3 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen This page has been automatically generated by Cargo's build. Do not edit it directly as it'll be overwritten next time it's generated ... [More] again. Container FeaturesFeature name Java Ant Maven2 Comment Container Instantiation ContainerFactory.createContainer("jetty8x"...) <cargo containerId="jetty8x".../> <containerId>jetty8x</containerId> Local Container Container Classpath Container Start Container Stop Container Timeout Embedded Container o.c.c.c.jetty.Jetty8xEmbeddedLocalContainer Installed Container o.c.c.c.jetty.Jetty8xInstalledLocalContainer Passing system properties Installer Remote Container o.c.c.c.jetty.Jetty8xRemoteContainer Configuration FeaturesFeature name Java Ant Maven2 Comment Standalone Local Configuration for installed container o.c.c.c.jetty.Jetty8xStandaloneLocalConfiguration Standalone Local Configuration for embedded container o.c.c.c.jetty.Jetty8xEmbeddedStandaloneLocalConfiguration Existing Local Configuration for installed container o.c.c.c.jetty.Jetty8xExistingLocalConfiguration Existing Local Configuration for embedded container Runtime Configuration o.c.c.c.jetty.JettyRuntimeConfiguration Static deployment of WAR Static deployment of expanded WAR Static deployment of EJB Static deployment of EAR Static deployment of RAR Static deployment of files Static deployment of OSGi Bundles Deployer FeaturesFeature name Java Ant Maven2 Comment Installed Deployer o.c.c.c.jetty.Jetty7xInstalledLocalDeployer Embedded Deployer o.c.c.c.jetty.Jetty7xEmbeddedLocalDeployer Remote Deployer o.c.c.c.jetty.JettyRemoteDeployer Other FeaturesFeature name Java Ant Maven2 Comment Debugging Supported Configuration propertiesThe tables below list both the general configuration properties as well as the container-specific ones. Standalone Local Configuration PropertiesFor installed container o.c.c.c.jetty.Jetty8xInstalledLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 6 or newer cargo.jetty.createContextXml JettyPropertySet.CREATE_CONTEXT_XML true cargo.jetty.servlet.default.useFileMappedBuffer JettyPropertySet.USE_FILE_MAPPED_BUFFER true cargo.jetty.session.path JettyPropertySet.SESSION_PATH N/A cargo.jvmargs GeneralPropertySet.JVMARGS N/A cargo.logging GeneralPropertySet.LOGGING medium cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.process.spawn GeneralPropertySet.SPAWN_PROCESS false cargo.protocol GeneralPropertySet.PROTOCOL http cargo.runtime.args GeneralPropertySet.RUNTIME_ARGS N/A cargo.servlet.port ServletPropertySet.PORT 8080 cargo.servlet.users ServletPropertySet.USERS N/A cargo.standalone.ignoreNonExistingProperties GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES false Datasource and Resource configuration In addition to the forementioned properties, this container configuration can also set up datasources and/or resources. For more details, please read: DataSource and Resource Support. For embedded container o.c.c.c.jetty.Jetty8xEmbeddedLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 6 or newer cargo.jetty.createContextXml JettyPropertySet.CREATE_CONTEXT_XML true cargo.jetty.servlet.default.useFileMappedBuffer JettyPropertySet.USE_FILE_MAPPED_BUFFER true cargo.jetty.session.path JettyPropertySet.SESSION_PATH N/A cargo.jvmargs GeneralPropertySet.JVMARGS N/A cargo.logging GeneralPropertySet.LOGGING medium cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.protocol GeneralPropertySet.PROTOCOL http cargo.runtime.args GeneralPropertySet.RUNTIME_ARGS N/A cargo.servlet.port ServletPropertySet.PORT 8080 cargo.servlet.users ServletPropertySet.USERS N/A cargo.standalone.ignoreNonExistingProperties GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES false Existing Local Configuration PropertiesFor installed container o.c.c.c.jetty.Jetty8xInstalledLocalContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.java.home GeneralPropertySet.JAVA_HOME JAVA_HOME version 6 or newer cargo.port.offset GeneralPropertySet.PORT_OFFSET 0 cargo.process.spawn GeneralPropertySet.SPAWN_PROCESS false cargo.protocol GeneralPropertySet.PROTOCOL http cargo.servlet.port ServletPropertySet.PORT 8080 If you specify cargo.runtime.args with --ini=anyfile.ini (where anyfile.ini points to a Jetty INI file), any property set in the CARGO Jetty container will be ignored and the ones read from the INI file used instead. Runtime Configuration PropertiesBefore using the Jetty remote deployer, please read: Jetty Remote Deployer For remote container o.c.c.c.jetty.Jetty8xRemoteContainerProperty name Java Property Supported? Default value Javadoc cargo.hostname GeneralPropertySet.HOSTNAME localhost cargo.remote.password RemotePropertySet.PASSWORD N/A cargo.remote.username RemotePropertySet.USERNAME N/A cargo.servlet.port ServletPropertySet.PORT 8080 Tested OnThis container is automatically tested on its server using the Codehaus Cargo Continous Integration System once a day. The server used for tests is downloaded from: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/8.1.11.v20130520/jetty-distribution-8.1.11.v20130520.tar.gzLink to the build plan: https://bamboo-ci.codehaus.org/browse/CARGO-SAMPLESJETTY8X View Online · View Changes Online [Less] |
||||||
|
Posted
5 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen Reference GuideThese are the various XML configuration elements that you can use to configure the Cargo Maven2 plugin. Make sure you also check the ... [More] use cases which show how to use them. Top level configuration elements Description Mandatory? Default value <configuration> Definition of a Configuration Defaults to a standalone configuration if the container is of type local and a runtime one if it's of type remote <container> Definition of a Container Defaults to a Jetty 7.x installed container if not specified <deployer> Definition of a Deployer Defaults to a deployer matching the container's type if none is specified (installed local deployer for an installed container, remote deployer for a remote container and embedded local deployer for an embedded container) <deployables> A list of deployables that are going to be deployed in the container when it is started or when cargo:deploy / cargo:undeploy is called. If the project's packaging is war, ear or ejb, the generated artifact is added automatically to the list of deployables to deploy. If you wish the generated artifact not to be added to the deployables list, just add an empty <deployer/> element. <daemon> Additional configuration that is used when deploying with the Cargo Daemon. For more information, please read: Cargo Daemon. <skip> Set this to true to bypass cargo execution Defaults to false <wait> Decides if Cargo should wait after the container is started or not. If using Cargo for integration tests, set it to false, otherwise Cargo will start the container and show the following message: Press Ctrl-C to stop the container... Important: This parameter has been deprecated and will be removed soon. If you want to do manual testing, please use the cargo:run MOJO. false The wait parameter Instead of tweaking your Maven project POM with the different values for the wait parameter, please use the cargo:run MOJO: The cargo:start MOJO should be used to start the container and hand over to the next Maven execution; i.e. it should ONLY be used for integration testing.The cargo:run MOJO will start the container and wait until the user decides to stop it by pressing CTRL + C, which implies that it should be used for manual testing. <configuration> elements Description Mandatory? Default value <configfiles> List of Configuration files that are to be added to a local container's configuration. Each file is specified using a <configfile> element. Cargo token replacement is applied to the files and any existing file is overwritten. No default <files> List of files that are to be added to a local container's configuration. Each file is specified using a <file> element. No default <home> For standalone configuration this is the location where Cargo will create the configuration and for existing configuration this is where it is located ${project.build.directory}/cargo/configurations/${containerId} <implementation> Full classname of a custom configuration implementation to use. In that case the custom configuration is registered with the <containerId> and <type> specified Defaults to the Cargo-provided implementation if not specified <properties> Values to use for various Configuration properties. You can also use the <propertiesFile> element to load configuration properties from a file. Default configuration properties Note that these configuration properties can also be overriden using Java properties; for example: mvn -Dcargo.servlet.port=8082 cargo:start In addition to this, properties can also be set using the Maven2 settings.xml file. See the setting configuration options via the Maven settings.xml section for details. <type> Configuration's type. Valid values are standalone, existing and runtime standalone <container> elements Description Mandatory? Default value <append> If true, then the file specified by <output> will not be erased across different runs false <containerId> Id of the container to use. Valid values can be found in the description page for each container jetty7x <dependencies> List of extra dependencies or shared dependencies that will be added to the container or applications execution classpath. No default <home> Location where the container is installed. If specified in conjunction with the <zipUrlInstaller> or <artifactInstaller> element, it will override the home directory defined by the installer No default If the user has not defined any home, <zipUrlInstaller> nor <artifactInstaller> element then the plugin will automatically attempt to download the container using the URL used by its tests (see the Tested On section of each container). <implementation> Full classname of a custom container implementation to use. In that case, the custom container is registered with the <containerId> and <type> specified Defaults to the Cargo-provided implementation if not specified <log> Path to a file where Cargo logs are saved Logs to the Maven console if no log file is specified <output> Path to a file where container logs are saved Logs to the file specified by the <log> element or to the Maven console if no such file has been specified <systemProperties> List of <key>value</key> pairs to be passed as System properties to the container when it is started. You can also use the <systemPropertiesFile> element to load system properties from a file. No default <timeout> The timeout after which Cargo reports an error if the container is not started or stopped 120000 ms (2 minutes) <type> The container's type. Valid values are installed, embedded and remote Default value is installed unless the <containerId> has not been specified, in which case the default is to use the Jetty 7.x installed container <zipUrlInstaller> Defines the location of a container distribution zip that will be downloaded and installed No default If the user has not defined any home, <zipUrlInstaller> nor <artifactInstaller> element then the plugin will automatically attempt to download the container using the URL used by its tests (see the Tested On section of each container). <artifactInstaller> Defines the location of a container Maven artifact that will be downloaded and installed No default If the user has not defined any home, <zipUrlInstaller> nor <artifactInstaller> element then the plugin will automatically attempt to download the container using the URL used by its tests (see the Tested On section of each container). <deployer> elements Description Mandatory? Default value <implementation> Deployer implementation class. Usage of this option is not recommended, please prefer type instead. No default <type> The deployer's type. Defaults to a deployer matching the container's type if none is specified (installed local deployer for an installed container, remote deployer for a remote container and embedded local deployer for an embedded container) <configfile> elements Description Mandatory? Default value <file> The configuration file or directory containing configuration files. No default <todir> The target directory, relative to configuration home, where the file should be copied If not specified, the file will be copied to the configuration's home directory <tofile> The target file name to use The original file name <file> elements Description Mandatory? Default value <file> The file, or directory, to add No default <todir> The target directory, relative to configuration home, where the file should be copied If not specified, the file will be copied to the configuration's home directory <tofile> The target file name to use The original file name <configfile> Indicates if Cargo token replacement should be applied (true) when copying. Do not use this option on a non-ascii file as it will corrupt it! false <overwrite> If any existing file should be overwritten or not true <deployable> elements Description Mandatory? Default value <artifactId> Maven artifact id for the module. This artifact id must match either the project's artifact id if your project generates a J2EE artifact (WAR, EAR, EJB and RAR) or it must match a specified <project>/<dependencies>/<dependency> artifact id Defaults to the project's artifact id <groupId> Maven group id for the module. This group id must match either the project's group id if your project generates a J2EE artifact (WAR, EAR, EJB and RAR) or it must match a specified <project>/<dependencies>/<dependency> group id Defaults to the project's group id <implementation> Deployable implementation class. Usage of this option is not recommended, please prefer type instead. No default <location> Path location where the module can be found Default's to the project's generated artifact location or to the specified <project>/<dependencies>/<dependency> location <pingURL> URL on which to ping the deployed or undeployed application (to check if deployment or undeployment is successful), that should return an HTTP OK response only after the deployment is complete. If not set, the deployed or undeployed application will not be pinged, hence the deployment considered as complete as soon as the target server's method returns successfully. No default <pingTimeout> If <pingURL> is set, the number of milliseconds after which the ping fails the build if still not successful. 20000 (i.e., 20 seconds) <properties> User-defined properties of a deployable. No default <type> Maven type for the module. This type must match either the project's packaging if your project generates a J2EE artifact (WAR, EAR, EJB and RAR) or it must match a specified <project>/<dependencies>/<dependency> type Defaults to the project's packaging <properties> elements Deployable Type Description Mandatory? Default value <context> WAR The context name to use when deploying the web application. If not specified, then the default context name is computed from the name of WAR itself (without the file extension) or <project>/<build>/<finalName> <war> WAR The path of the WAR being deployed. Default's to the project's generated artifact location <ear> EAR The path of the EAR being deployed. Default's to the project's generated artifact location <name> EAR The name of EAR deployable (it can be anything, there's no special rule). If not specified, it is computed from the EAR's file name (removing the filename extension) or <project>/<build>/<finalName> <ejb> EJB The path of the EJB being deployed. Default's to the project's generated artifact location About WAR contexts Many containers have their specific files for redefining context roots (Tomcat has context.xml, JBoss has jboss-web.xml, etc.). If your WAR has such a file, the server will most probably use the context root defined in that file instead of the one you specify using the CARGO deployer. <dependency> elements Description Mandatory? Default value <artifactId> Maven's artifact id. This artifact id must match a specified <project>/<dependencies>/<dependency> artifact id Defaults to the project's artifact id <groupId> Maven's group id. This group id must match a specified <project>/<dependencies>/<dependency> group id Defaults to the project's group id <type> Maven's type. This type must match a specified <project>/<dependencies>/<dependency> type Defaults to the project's packaging <classpath> Target classpath, either extra (default) or shared. Shared application classpath deployment is only available for local containers which support shared Application Classpaths. extra (container classpath) <location> The path of a folder or a jar file you wish to add to deployable classpath. This element can be used to explicitly add entries to the classpath. For example: <dependency> <location>src/main/resources/conf</location> </dependency> If the groupId and artifactId match those of the project then the deployable is the artifact generated by the project. Otherwise the location is the location of the dependency in your local respository. <zipUrlInstaller> elements Description Mandatory? Default value <url> URL from which to download the container's ZIP or TAR.GZ file. No default <downloadDir> Directory in which the zipUrlInstaller should download the container's ZIP or TAR.GZ file. ${java.io.tmpdir}/cargo/installs <extractDir> Directory in which the zipUrlInstaller should extract the container's ZIP or TAR.GZ file. ${project.build.directory}/cargo/installs <proxy> Proxy server settings, if required. No default Automatic proxy settings Note that CARGO will by default reuse existing Maven2 proxy configuration -so you won't need to type the proxy settings for the zipUrlInstaller element. <proxy> elements (under the zipUrlInstaller element) Description Mandatory? Default value <cargo.proxy.host> Proxy host name or IP address. No default <cargo.proxy.port> Proxy port. Very probably 80 <cargo.proxy.user> User name to connect to the proxy server. No default <cargo.proxy.password> Password to connect to the proxy server. No default <artifactInstaller> elements Description Mandatory? Default value <groupId> Group id. No default <artifactId> Artifact id. No default <version> Version. No default <type> Artifact type. zip <classifier> Classifier. No default <extractDir> Directory in which the artifactInstaller should extract the container's ZIP or TAR.GZ file. ${project.build.directory}/cargo/installs Daemon configurationThe Cargo Daemon is a Web-based application that uses the Cargo API to configure, start and stop containers on a remote machine. The daemon is meant to be listening 24/7, to allow users to deploy new containers and web applications at their command. For more information, please read: Cargo Daemon. Container configuration for the Daemon For the Maven2/Maven3 plugin, the "daemonized server" is actually a local container with a hostname that points to a remote machine. This implies that: You should not set the container type to a remote container nor add any remote deployers to the configuration; but instead define the container as a local container (with either a standalone or existing configuration)When you define the home paths for the container and the configuration, remember these paths are for the machine where the Daemon is running (and, preferably, use absolute paths)When you call cargo:daemon-start, the Maven2/Maven3 plugin will do the following: If an installer is defined: Download the archive locallySend the archive over to the machine running the DaemonInstruct the Daemon to extract the archiveIf a standalone local configuration is defined, instruct the Daemon to create itIn all cases: Send the configuration files and deployables to the machine running the DaemonInstruct the Daemon to deploy themFinally, instruct the Daemon to start the container<daemon> elements Description Mandatory? Default value <classpaths> A list of <classpath>myclasspath</classpath> items, that will be added by the JVM launcher when starting a container. No default <properties> A list of properties used to configure the Cargo Daemon. No default <properties> elements Description Mandatory? Default value <cargo.daemon.url> URL to connect with the daemon. No default <cargo.daemon.handleid> The handle id to register this container with. No default <cargo.daemon.autostart> When set to true, the dameon will automatically restart the container if the daemon notices it is stopped. false Setting configuration options via the Maven settings.xmlThe Cargo Maven2/Maven3 plugin also allows you to define container configuration properties using the settings.xml file. This way, you can for example store properties like usernames and passwords in a centralized location (as opposed to pom.xml files). First, add the configuration properties you would like in your settings.xml file's <servers> section: <servers> <server> <id>jonas1</id> <configuration> <cargo.remote.uri>jmx://jonas1</cargo.remote.uri> <cargo.jonas.domain.name>jonas</cargo.jonas.domain.name> <cargo.remote.username>jonas</cargo.remote.username> <cargo.remote.password>jonas</cargo.remote.password> </configuration> </server> <servers> Then, in the Cargo plugin's configuration, use the cargo.server.settings property in order to reference the configuration properties that you have previously defined. For example: <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> [...] <configuration> <properties> <cargo.server.settings>jonas1</cargo.server.settings> </properties> </configuration> </configuration> </plugin> In this case, the plugin will internally "expand" the configuration into: <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> [...] <configuration> <properties> <cargo.remote.uri>jmx://jonas1</cargo.remote.uri> <cargo.jonas.domain.name>jonas</cargo.jonas.domain.name> <cargo.remote.username>jonas</cargo.remote.username> <cargo.remote.password>jonas</cargo.remote.password> </properties> </configuration> </configuration> </plugin> Careful with properties set in the POM Priority for property values are as follows: Highest priority: Properties set using environment variablesSecond priority: Properties that should be loaded using the cargo.server.settings optionThird priority: Properties loaded from a fileLowest priority: Properties set in the POM View Online · View Changes Online [Less] |
||||||
|
Posted
7 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen DefinitionRe-use an existing container installationExplanationsAn existing configuration plugs itself onto an existing container installation that ... [More] exists on your hard disk. This is by opposition to the Standalone Local Configuration which creates a new container installation from scratch in a directory of your choice. Existing configurations require that the user creates a valid configuration directory and points Cargo to it. Whenever you configure or start a container which uses an existing configuration, Cargo will: Copy all configuration filesPerform a local deployment of all deployablesAs a result, Cargo will not be configuring the configuration properties nor the data sources and resources on your container; these need to be configured beforehand. Please note that this method does not guarantee reproducibility, as the configuration is not "cleaned" at any point. If you want to keep a generated configuration you can ask Cargo to generate a standalone configuration once and then consider it an existing configuration. Support MatrixJava Ant Maven2 Java APIThere are different ways of using an existing configuration: By directly instantiating the configuration matching your container. For example: [...] Configuration configuration = new ResinExistingLocalConfiguration("target/resin3x"); [...] By using the DefaultConfigurationFactory which automatically maps the right implementation for the container you're using. For example: [...] ConfigurationFactory factory = new DefaultConfigurationFactory(); Configuration configuration = factory.createConfiguration("resin3x", ContainerType.INSTALLED, ConfigurationFactory.EXISTING, "c:/apps/resin-3.0.9"); [...] Ant TaskExample: <cargo containerId="resin3x" [...]> <configuration type="existing" home="c:/apps/resin-3.0.9"/> [...] </cargo> Maven2 Plugin [...] <container> <containerId>resin3x</containerId> [...] </container> <configuration> <type>existing</type> <home>c:/apps/resin-3.0.9</home> </configuration> [...] View Online · View Changes Online [Less] |
||||||
|
Posted
7 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen DefinitionConfigures your container in a specific directoryExplanationThe standalone configuration allows configuring your container so that it is ... [More] setup to start in a directory you choose (see the configuration page for more general explanations). Whenever you configure or start a container which uses a standalone configuration, Cargo will: Delete the configuration directoryCreate a new configuration in that directory, with all configuration properties (including data sources and resources)Copy all configuration filesPerform a local deployment of all deployablesThe reason for this behavior is reproducibility which is for example very useful for automated testing. If you wanted to keep a generated configuration you could ask Cargo to generate a standalone configuration once and then consider it an existing configuration. Support MatrixJava Ant Maven2 Java APIThere are different ways of using a standalone configuration: By directly instantiating the configuration matching your container. For example: By using the DefaultConfigurationFactory which automatically maps the right implementation for the container you're using. For example: Ant Task <cargo containerId="resin3x" [...]> <configuration type="standalone" home="target/resin3x"/> [...] </cargo> Maven2 Plugin [...] <container> <containerId>resin3x</containerId> [...] </container> <configuration> <type>standalone</type> <home>target/resin3x</home> </configuration> [...] Note that the standalone configuration is the default for the Maven 2 plugin so specifying only the following would also work: [...] <container> <containerId>resin3x</containerId> [...] </container> [...] View Online · View Changes Online [Less] |
||||||
|
Posted
8 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen DefinitionThe configuration files are the files to add to your container's configuration. It is internally used by some containers and is ... [More] accessible for you can to add extra files.This feature is only available for local containers (i.e., not for remote containers nor any kind of deployers). ExplanationIn some cases, it is necessary to enrich your container configuration with extra files. This can be done using Cargo's configFiles option, accessible via the Cargo APIs. The advantage of using this option is that it can replace configuration properties in your files: simply use, for example, @cargo.servlet.port@ to have it replaced with the port on which the Servlet/JSP container is listening to. Careful with binary files! If you want to inject binary configuration files (JAR files, for example), you should use setFileProperty (instead of setConfigFileProperty) with the Java API and <files> and <file> (instead of <configfiles> and <configfile>) with the Maven2/Maven3 plugin. You might for example want to add the advanced login configuration to your JBoss instance. Example using the Java APIThe method's name is setConfigFileProperty rather than addConfigFileProperty; but it actually adds files to the configFiles list. LocalContainer container = ...; StandaloneLocalConfiguration configuration = (StandaloneLocalConfiguration) getLocalContainer().getConfiguration(); FileConfig loginConfigXml = new FileConfig(); loginConfigXml.setConfigfile("src/main/jboss5/login-config.xml"); loginConfigXml.setToDir("conf"); configuration.setConfigFileProperty(loginConfigXml); FileConfig sampleRolesProperties = new FileConfig(); sampleRolesProperties.setConfigfile("src/main/jboss5/sample-roles.properties"); sampleRolesProperties.setToDir("conf"); configuration.setConfigFileProperty(sampleRolesProperties); FileConfig sampleUsersProperties = new FileConfig(); sampleUsersProperties.setConfigfile("src/main/jboss5/sample-users.properties"); sampleUsersProperties.setToDir("conf"); configuration.setConfigFileProperty(sampleUsersProperties); Example using the ANT tasks <cargo containerId="@{containerId}" action="@{action}"> <configuration home="${configuration.home}"> <configfile file="${basedir}/src/main/jboss5/login-config.xml" todir="conf"/> <configfile file="${basedir}/src/main/jboss5/sample-roles.properties" todir="conf/props"/> <configfile file="${basedir}/src/main/jboss5/sample-users.properties" todir="conf/props"/> </configuration> </cargo> Example using the Maven 2 plugin <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> <container> [...] </container> <configuration> <type>standalone</type> [...] <configfiles> <configfile> <file>${project.basedir}/src/main/jboss5/login-config.xml</file> <todir>conf</todir> </configfile> <configfile> <file>${project.basedir}/src/main/jboss5/sample-roles.properties</file> <todir>conf/props</todir> </configfile> <configfile> <file>${project.basedir}/src/main/jboss5/sample-users.properties</file> <todir>conf/props</todir> </configfile> </configfiles> </configuration> </configuration> </plugin> More advanced example: adding the jetty-env.xml fileTo define a central jetty-env.xml file and reuse it later from your WARs, you can proceed as follows: As explained on the top of this page, use a standalone local container (i.e., not an embedded configuration) Make sure the property JettyPropertySet.CREATE_CONTEXT_XML (i.e. cargo.jetty.createContextXml) is set to false; so that CARGO doesn't create a context.xml file for your WAR's deployable but rather copies it from the source to the configuration home folder. For each deployable, make sure the deployable is defined as an expanded WAR; as explained on the Static deployment of expanded WAR page. Finally, for each deployable, add the following to your local container's configuration: <configfiles> <configfile> <file>${basedir}/src/main/config/jetty-env.xml</file> <todir>webapps/webapp-context/WEB-INF</todir> </configfile> </configfiles> ... where webapp-context is the Web application's context This way: To deploy your WAR, CARGO will copy your WAR's expanded version (i.e., the WAR directory) into the webapps subdirectory of the Jetty configurationOnce the WAR is copied, CARGO will also copy the jetty-env.xml file into that WAR's WEB-INF directoryAs a reference, please find below the full configuration for Jetty 7.x: <configuration> <container> <containerId>jetty7x</containerId> <zipUrlInstaller> <url> http://download.eclipse.org/jetty/7.6.3.v20120416/dist/jetty-distribution-7.6.3.v20120416.zip </url> </zipUrlInstaller> </container> <configuration> <home>${project.build.directory}/jetty-home</home> <properties> <cargo.jetty.createContextXml>false</cargo.jetty.createContextXml> </properties> <configfiles> <configfile> <file>${project.basedir}/src/main/config/jetty-env.xml</file> <todir>webapps/datasource-war/WEB-INF</todir> </configfile> </configfiles> </configuration> <deployables> <deployable> <groupId>org.codehaus.cargo</groupId> <artifactId>datasource-war</artifactId> <type>war</type> <location>datasource-war-extracted</location> <properties> <context>datasource-war</context> </properties> </deployable> </deployables> </configuration> View Online · View Changes Online [Less] |
||||||
|
Posted
8 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen IntroductionThe Cargo Daemon is a Web-based application that uses the Cargo API to configure, start and stop containers on a remote ... [More] machine. The daemon is meant to be listening 24/7, to allow users to deploy new containers and web applications at their command. It can be accessed using a browser-based UI, via Java API or Maven2 plugin. Why use the Cargo Daemon?Most web containers (e.g. Tomcat, Jetty) provide built-in remote deployment facilities already, also many of them already have daemon integrations; so why use the Cargo Daemon? During intense redeployment (i.e., testing and even sometimes QA or production hot deployments): All of the remote deployment facilities that keep the JVM alive will eventually suffer from the dreaded java.lang.OutOfMemoryError: PermGen space exception if something in the web application is leaking memory. Most web containers try their best to track down these 'dead' objects and forcefully remove them, but it does not always succeed to reclaim the memory. With a leaking web application, the available memory starts to shrink after each redeploy, and eventually the memory is exhausted. The only solution to this is to kill the JVM, and restart it. And that is exactly what the Cargo Daemon tries to manage. It will try to shutdown the web application cleanly, but if that fails it will forcefully kill the JVM. It is the only way to guarantee that a new version of your web application always starts when you want it to.In heterogeneous environments: With Cargo, the way you configure the container is independent from the underlying server -you can set the different configuration properties, define datasources, add deployables, etc. transparently. You can therefore use the Cargo Daemon as a container-independent daemon, with support for the generation of the proper configuration on all supported containers.During upgrades and/or application server product evaluations: As Cargo is not dependent on the application server nor on its version, you can easily reuse an existing Cargo Daemon setup to use it for another version of a container, or another container altogether; without having to worry about understanding how to configure it.Table of ContentsThe documentatation for the Cargo Daemon includes: Installation: explains how to install and run the daemonGetting started: very quick guide on using the daemonInstallationJava versions for running the Daemon Cargo Daemon requires Java 6 or greater in order to run in standalone mode. If you deploy the Cargo Daemon WAR file on an existing container, the minimum requirement is Java version 5. To install and run the Cargo Daemon: Download the Cargo Daemon from the Downloads pageExecute by typing: java -jar target/cargo-daemon-webapp-<version>.war where <version> is the version number of the daemon that you have downloaded. By default, the Cargo Daemon will run on HTTP port 18000. To change it, use the -p option: java -jar target/cargo-daemon-webapp-<version>.war -p 18001 Additionally, Cargo Daemon will save log files in the cargo home directory unless the -nologging option is used. Note that the Cargo Daemon is a WAR file; you can actually also deploy it as a WAR on any existing container. This can be useful if you want to, for example, reuse a certain security configuration. The daemon also accepts other parameters, in the form of system properties: Property name Description Mandatory? Default value daemon.home Directory in which the standaone daemon server stores its files. These include the temporary files (such as its own WAR and server temporary files) as well as the server log files (AWS-xxxxxxxxxxxxx.log, where xxxxxxxxxxxxx is the timestamp at which the deamon was started). This property is not used and completely ignored if the daemon WAR file is deployed on an existing container. ${user.home}/.cargo cargo.home Directory in which the daemon (be it standalone or deployed on an existing container) stores the list of containers, downloaded container archives, container logs, etc. ${user.home}/.cargo Note that the standalone daemon by default sets this to ${daemon.home} Getting started using the browser UITo use the Cargo Daemon via the browser UI, simply open http://<machine>:<port>/ -where <machine> is the machine host name or IP address and <port> is the port number used (default is 18000): To start a container, fill in the form and press Start: To stop, restart, delete or view logs of a container, use the actions on the containers list: The Cargo Daemon keeps a persistent record on disk of all the containers that have been submitted. Containers that have been submitted will stay in the list, even when they are stopped. This allows you to manually restart them, or view the logs even after the container is stopped.If you want the container to be removed from the list, simply press the delete button.Containers can also be submitted with the autostart property, this will automatically restart the container if the daemon notices it is stopped.Getting started with the Java API / Maven2/Maven3 pluginAs stated before, the Cargo Daemon is also available programmatically: The details of the Java API can be seen on the Javadoc for o.c.c.tools.daemon.DaemonClientThe details of the configuration for the Maven2/Maven3 plugin is documented in the Daemon configuration section of the Maven2/Maven3 plugin reference guide and the example can be seen via the Daemon archetype. Java versions for connecting to the Daemon via Java API or Maven2/Maven3 plugin In order to connect to the Daemon via Java API or Maven2/Maven3 plugin, the minimum requirement is Java version 5. To get the required libraries for using the Daemon via Java API, please check the Downloads page. View Online · View Changes Online [Less] |
||||||
|
Posted
8 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen DefinitionCargo provides Ant tasks to perform all the operations available from the Java APIFunctional tests The usage of Cargo for executing ... [More] functional tests on a container does not mandate these ANT tasks. You could directly use the Cargo Java API from your Java unit test classes (JUnit, TestNG, etc), as described on the Functional testing page. ExplanationBefore using the Ant API you need to register the Cargo Ant tasks into Ant. This is done in the following manner: <taskdef resource="cargo.tasks"> <classpath> <pathelement location="${cargo-core-uberjar.jar}"/> <pathelement location="${cargo-ant.jar}"/> </classpath> </taskdef> Some additional dependencies might also be required for the ANT task. Please see the Installation page for details. The Cargo ANT tasks in detailHere are the different task actions available to call on this plugin: Action Description start Start a container. That task will: If the task configuration requires so, installs the container.If the task configuration defines a container with a standalone local configuration, it will create the configuration.If the task configuration contains one or more deployables, it will deploy these to the container automatically.And, of course, start the container.Note: A container that's started with the start task will automatically shut down as soon as the parent ANT instance quits (i.e., you see a BUILD SUCCESSFUL or BUILD FAILED message). If you want to start a container and perform manual testing, see our next task run. run Start a container and wait for the user to press CTRL + C to stop. That task will: If the task configuration requires so, installs the container.If the task configuration defines a container with a standalone local configuration, it will create the configuration.If the task configuration contains one or more deployables, it will deploy these to the container automatically.And, of course, start the container and wait for the user to press CTRL + C to stop.stop Stop a container. restartStop and start again a container. If the container was not running before calling restart, it will simply be started. configure Create the configuration for a local container, without starting it. Note that the start and run actions will also install the container automatically. deploy Deploy a deployable to a running container. undeploy Undeploy a deployable from a running container. redeploy Undeploy and deploy again a deployable. If the deployable was not deployed before calling redeploy, it will simply be deployed. Wait after the container has started Many wonder the difference between the start and run actions: If you want to just start the container and then do other tasks (for example, execute tests), use the start action. That action should therefore ONLY be used for integration testing.If you want start the container and have ANT "blocked" afterwards (i.e., until you press CTRL + C to stop), use the run action. run is therefore the action to use for manual testing.Examples Orion 2.xHere's a full example showing how to deploy a WAR, and expanded WAR and an EAR in an Orion 2.x container. Please note that the output and log attribute are optional. The property elements allow you to tune how the container is configured. Here we're telling it to start on port 8180 and to generate the maximum amount of logs in the container output file. <taskdef resource="cargo.tasks"> <classpath> <pathelement location="path/to/cargo-uberjar.jar"/> <pathelement location="path/to/cargo-ant-tasks.jar"/> </classpath> </taskdef> <cargo containerId="orion2x" home="c:/apps/orion-2.0.3" output="target/output.log" log="target/cargo.log" action="start"> <configuration> <property name="cargo.servlet.port" value="8180"/> <property name="cargo.logging" value="high"/> <deployable type="war" file="path/to/my/simple.war"/> <deployable type="war" file="path/to/my/expandedwar/simple"/> <deployable type="ear" file="path/to/my/simple.ear"/> </configuration> </cargo> Tomcat 5.xThis example gives a walk through of how to get a Cargo Ant build to work with Tomcat 5.x . PrerequisitesIt is assumed that Tomcat 5.x is already installedThe cargo-core-uberjar.jar and cargo-ant.jar JARs have been downloadedA mimimum knowledge of Ant is requiredUser already has a war target that properly generates a working war fileStepsFollow the following steps to configure your build.xml : Create a folder under your basedir called cargolib that will hold cargo-core-uberjar.jar and cargo-ant.jarDefine a property for cargolib <property name="cargolib.dir" value="${basedir}/cargolib"/> Define 2 new properties cargo-uberjar and cargo-antjar as shown below: <property name="cargo-uberjar" value="${cargolib.dir}/cargo-core-uberjar.jar"/> <property name="cargo-antjar" value="${cargolib.dir}/cargo-ant.jar"/> Add additional properties for defining the following: Property Description tomcat.home Installation directory of tomcat5x tomcatlog.dir This is where our logs are going to be generated tomcatconfig.dir Cargo needs an empty config folder pathtowarfile The full path of the war file e.g c:/devtools/myapp/dist/myfile.war Add the following code to your build.xml : <taskdef resource="cargo.tasks"> <classpath> <pathelement location="${cargo-uberjar}"/> <pathelement location="${cargo-antjar}"/> </classpath> </taskdef> <target name="cargostart" depends="war"> <delete dir="${tomcatconfig.dir}" /> <mkdir dir="${tomcatlog.dir}"/> <mkdir dir="${tomcatconfig.dir}"/> <echo message="Starting Cargo..."/> <echo message="Using tomcat.home = ${tomcat.home} "/> <echo message="Using war = ${mywarfile} "/> <echo message="Jars used = ${cargo-uberjar} , ${cargo-antjar}"/> <cargo containerId="tomcat5x" home="${tomcat.home}" output="${tomcatlog.dir}/output.log" log="${tomcatlog.dir}/cargo.log" action="start"> <configuration home="${tomcatconfig.dir}"> <property name="cargo.servlet.port" value="8080"/> <property name="cargo.logging" value="high"/> <deployable type="war" file="${mywarfile}"/> </configuration> </cargo> </target> Remote deploymentHere's a full example showing how to deploy a WAR to a remote Tomcat 6.x container. <taskdef resource="cargo.tasks"> <classpath> <pathelement location="path/to/cargo-uberjar.jar"/> <pathelement location="path/to/cargo-ant-tasks.jar"/> </classpath> </taskdef> <cargo containerId="tomcat6x" action="deploy" type="remote"> <configuration type="runtime"> <property name="cargo.hostname" value="production27"/> <property name="cargo.servlet.port" value="8080"/> <property name="cargo.remote.username" value="admin"/> <property name="cargo.remote.password" value=""/> <deployable type="war" file="path/to/simple-war.war"> <property name="context" value="application-context"/> </deployable> </configuration> </cargo> For more details, please check the example in the Remote Container section for the ANT tasks. The ANT tasks support the deployer actions deploy, undeploy and redeploy. View Online · View Changes Online [Less] |
||||||
|
Posted
8 days
ago
by
S. Ali Tokmen
Page edited by S. Ali Tokmen Getting StartedVery quick startCARGO can be directly run on any existing Maven2 Java EE project (WAR, EAR or other) by running: mvn clean ... [More] verify org.codehaus.cargo:cargo-maven2-plugin:run This will create a default Jetty 7.x installed local container and start it using the Cargo Maven2 plugin with your Maven2 project's deployable (a WAR, for example) deployed to it; so you can run manual tests (as a first introduction). What is magic is that if you now want to run the same tests with Tomcat 7.x you simply need to run (in one line): mvn clean verify org.codehaus.cargo:cargo-maven2-plugin:run -Dcargo.maven.containerId=tomcat7x -Dcargo.maven.containerUrl=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.16/bin/apache-tomcat-7.0.16.zip That command will automatically download Tomcat 7.0.16 from the specified URL (taking into account any proxy server setting you would have in Maven2/Maven3), instantiate the container, create a local configuration with your application and run it. It will also save the downloaded container in the default directory (see the Maven2 Plugin Reference Guide for details), so it won't get downloaded when you run the same command twice. Now, if you want to run this time on Glassfish 3.x with with the HTTP port set to 9000, run: mvn clean verify org.codehaus.cargo:cargo-maven2-plugin:run -Dcargo.maven.containerId=glassfish3x -Dcargo.maven.containerUrl=http://download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip -Dcargo.servlet.port=9000 CARGO's main advantage is that the commands and configuration remains the same for any version of any container supported by CARGO -be it Tomcat, Jetty, JBoss, JOnAS, GlassFish, WebLogic, etc. Like it? Well, keep on reading, then! More examplesAs usual the best way to learn to use a tool is through examples. We have several Maven2 Archetypes that contain sample Maven2/Maven3 projects with different use cases for the CARGO plugin, we would really recommend that you check them out. For more details, read here: Maven2 Archetypes. In addition here are the typical uses cases covered by the plugin: Deploying to a running containerGenerating a container configuration deployment structureMerging WAR filesStarting and stopping a container The Cargo Maven plugin in detailHere are the different goals available to call on this plugin: Goals Description cargo:start Start a container. That goal will: If the plugin configuration requires so, installs the container.If the plugin configuration defines a container with a standalone local configuration, it will create the configuration.If the plugin configuration contains one or more deployables, it will deploy these to the container automatically.If the plugin configuration contains no deployables but the project's packaging is Java EE (WAR, EAR, etc.), it will deploy the project's deployable to to the container automatically.And, of course, start the container.Note: A container that's started with cargo:start will automatically shut down as soon as the parent Maven instance quits (i.e., you see a BUILD SUCCESSFUL or BUILD FAILED message). If you want to start a container and perform manual testing, see our next goal cargo:run. cargo:run Start a container and wait for the user to press CTRL + C to stop. That goal will: If the plugin configuration requires so, installs the container.If the plugin configuration defines a container with a standalone local configuration, it will create the configuration.If the plugin configuration contains one or more deployables, it will deploy these to the container automatically.If the plugin configuration contains no deployables but the project's packaging is Java EE (WAR, EAR, etc.), it will deploy the project's deployable to to the container automatically.And, of course, start the container and wait for the user to press CTRL + C to stop.cargo:stop Stop a container. cargo:restart Stop and start again a container. If the container was not running before calling cargo:restart, it will simply be started.cargo:configure Create the configuration for a local container, without starting it. Note that the cargo:start and cargo:run goals will also install the container automatically (but will not call cargo:install). cargo:package Package the local container. cargo:daemon-startStart a container via the daemon. Read more on: Cargo Daemoncargo:daemon-stopStop a container via the daemon. Read more on: Cargo Daemoncargo:deployer-deploy (aliased to cargo:deploy) Deploy a deployable to a running container. cargo:deployer-undeploy (aliased to cargo:undeploy) Undeploy a deployable from a running container. cargo:deployer-start Start a deployable already installed in a running container. cargo:deployer-stop Stop a deployed deployable without undeploying it. cargo:deployer-redeploy (aliased to cargo:redeploy) Undeploy and deploy again a deployable. If the deployable was not deployed before calling cargo:deployer-redeploy (or its alias cargo:redeploy) it will simply be deployed. cargo:uberwar Merge several WAR files into one. cargo:install Installs a container distribution on the file system. Note that the cargo:start goal will also install the container automatically (but will not call cargo:install). cargo:help Get help (list of available goals, available options, etc.). The configuration elements are described in the Reference Guide section. View Online · View Changes Online [Less] |
||||||
|
Posted
12 days
ago
by
JIRA ji...@codehaus.org
|
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.