[ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-8141: ---------------------------------------- Thanks, [~simkam]. FWIW, I wrote this to [~maeste] and [~aloubyansky] a week or so ago in relation to a different problem this resource causes: --------------------- Hi guys, This is a follow up to the chat Alexey and I had about the CCM resource earlier today. Basic summary is the RA subsystem parser ensures that an add op for the CCM resource is always part of the boot ops, so if the JCA subsystem has been parsed, there’s automatically a CCM resource. And the user can’t remove and readd it. The current situation (which dates to the beginning I guess) violates the requirement that you don’t have to use xml editing to configure. You can’t start with a config with no JCA subsystem, then via the CLI add it and then configure the CCM resource. At least not without a reload in the middle. Not having to us xml to configure has always been a requirement but with the offline CLI and the new provisioning stuff based on it, it’s an even stronger requirement now. I see a couple options: 1) a) Make the CCM add op public again, b) Drop the automatic add from the parser. Parser only creates the add op if the xml configures it c) Have JcaSubsystemAdd add a step that checks if the CCM resource exists (in case user configured it in xml or in the same composite that adds subsystem=jca) and if not that step in turn adds a step that executes the CachedConnectionManagerAdd op with the default params d) Make CachedConnectionManagerRemove a normal remove again; removes the resource and requires reload 2) Add a parameter to the JCASubsystemAdd op. Complex object, fields are the same as the attributes in the CCM resource. Users can configure CCM when adding the JCA subsystem by setting this parameter. If present, JCASubsystemAdd takes the values in the param and adds a step that executes the CachedConnectionManagerAdd op. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- Since the add op was actually useful in domain mode, it seems like 1) is what we need to do. Otherwise we've introduced an incompatible API change. Removing it was based on my mistaken belief that it was a useless operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)