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

« Previous Version 5 Next »


Specifies how the container is configured


The notion of Configuration is different from the notion of Installation. Indeed a container is installed in the place where you have installed it (or where the Cargo Installer has installed it).

However, it is possible to configure this container to tell it deploy archives to some other directories and consider this other directory as the new home directory of the container. All containers support this feature. This allows to leave an installed container directory intact (no modifications) and to compartiment all modifications to some directory that you are controlling. Say you wish to automate some functional tests. You can set the new container home to point to your temporary build directory. This is the configuration we call Standalone configuration.

By opposition if you choose to use the default configuration that your container has set up when you installed it, it is called an Existing configuration.

Please note that at the moment Cargo only implementsStandalone configurations for all the supported containers. However, you can create your own implementation if you wish (see below).

Custom configuration

The Cargo API allow the user to plug his/her own custom configuration implementation. The only requisites is that the implementation must implements ContainerConfiguration and have 2 constructors: MyCustomConfiguration(Container) and MyCustomConfiguration(Container, File homeDir).

You can then register your configuration against the ConfigurationFactory class. It's optional and only required if you want to let users use ConfigurationFactory to instantiate your configuration. You would write:

Where customhint is any value you wish, used to differentiate your configuration from other existing ones associated with the container represented by its id.

  • No labels