Currently in WF 10, when a resource adapter is created / deleted using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF. We need ability avoid the restart of the server

Why We need it?

In Teiid, it is common practice to add/remove resource adapters dynamically and restarting server will affect performance and usability severely.

• Because delete/re-add is in Teiid's workflow to manage a resource adapters and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.

• Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.

• Every time resource adapter starts we fetch metadata from the source, this is very expensive operation.

• With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.

• This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature

As per Teiid project is concerned, we consider this is regression on WF and thus a bug.

Proposed Solution

bstansbe@redhat.com suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-ApplyingUpdatestoRuntimeServices

Based on this the conclusion is that resource adapters, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new RA is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.

Workarounds Considered

Teiid currently deploy the RAR files in module format (due to product requirements) if allowed this can be changed to deploy .rar files, which is suggested as alternative. This does require lot of code changes and not approved path. Aslo, only half solution as WFLY-6773 we would still need.