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 to deploy archives to some custom directory and consider this directory as the new home directory. All local 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.
For remote containers, configuration stores the URI required to manipulate the container.
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 a
CustomConfiguration(URI home) constructor (for local containers,
home is the URI pointing to directory from where to start the container; for remote containers,
home is the URI required to manipulate the container).
You can then register your configuration against the
DefaultConfigurationFactory class. It's optional and only required if you want to let users use the
DefaultConfigurationFactory class to instantiate your configuration. You would write:
new ConfigurationType("customhint") is to create a type of configuration, used to differentiate your configuration from other existing ones associated with the container represented by its id. You could of course implement an existing type such as