rhq-project/rhq — pull request #80 by metlos (2014-07-11 15:41:58+00:00)
Title: BZ 1069547 / JON3-10  Support EAP 6.2/6.3 style patching

This PR is separated into 2 commits, the messages of which detail the changes in them:

## Support for API-based bundle handlers

This is to support new type of dedicated bundle handlers able to do more than just file-system modifications. In order to enable them to e.g. connect to some remote endpoint, a more complex configuration data needs to be passed over.

This creates coupling between the bundle destination definition and the handler that is able to deploy to such destinations (because it needs to be able to use the configuration offered by the destination definition) but that is unavoidable given the specific things the handlers would be doing.

* The resource types can use the new "destination-definition" tag under bundle target to define new type of destinations that can use a "connection string" expression + can pass all or parts of resource or plugin configs or traits to the bundle handler.

* The agent-side bundle handlers have access to the bundle deployment configuration even in the purge scenario. This is to support the more complex bundle handlers needing the config to better identify the bundle deployment.

* The deploy directory is no longer a required argument when creating a bundle destination. This is because for the API based bundle handlers, such configuration property might not make any sense and would only create confusion on the user side.

* It is no longer required for the server bundle plugins to come up with the full list of the required files upon reading the recipe alone. The bundle plugins can therefore choose whether they support piece-wise
upload of the bundle version or only support uploading a full bundle distribution file.

## Wildfly patching by various means

* **Bundles** - using a dedicated bundle type. This enables us to understand the patch zip file as our bundle without any RHQ specific recipe. We can supply various parameters to patch application process but although revert is supported, it cannot be configured by any parameters as one can do over Wfly's CLI.

* **Content** - patches appear as packages of the AS7 standalone server. They are discoverable and can be installed from repositories (without any possibility of customizing the install process). Delete (i.e. rollback)
is supported, again without configuration.

* **Rollback through operation** - in case user would need special behavior on rollback, they can use a dedicated operation on the AS7 standalone server resource.

* **Bundle handover** - patches can be installed using the bundle handover facility, too, using the "patch" action. This is configurable using handover parameters and supports all the parameters available in Wfly's
CLI.