[jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add operation excepts no parameters anymore

[ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-8141: ---------------------------------------- Scratch my #1 and #2 above. I think these are the requirements around this: 1) If a user *boots* a config with subsystem=jca in it but nothing that specifies CCM use, they should be able to go to the CLI and do this: [standalone@localhost:9999 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=install,value=true) That should work even though their config didn't specify anything to trigger adding the /subsystem=jca/cached-connection-manager=cached-connection-manage resource. This needs to work to be compatible with previous behavior, not because it's good. 2) Users starts a standalone server or domain profile with no JCA subsystem and then can do this: /profile=default-web/subsystem="jca":add() /profile=default-web/subsystem="jca"/cached-connection-manager="cached-connection-manager":add() (For the standalone server case ignore the /profile=default-web part). This needs to work or we have a regression. That's the main point of this JIRA. Fixing this will also fix Alexey's problem. 3) We want the WFY-2640 scenario to work: a) boot with JCA subsystem present b) With CLI: {code} [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] :reload { "outcome" => "success", "result" => undefined } [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add { "outcome" => "success", "result" => undefined } {code} The only way I see to meet all these objectives is to make the add handler public again, and rewrite it to not fail if the resource is already present, but is configured with all default values (i.e. interpret that state as meaning the resource was auto-added by the parser). The resource must always be present after boot for 1) to work. The add op must be public for 2). And for 3) to work in combination with 1), the add handler can't reject the add just because the parser already auto-added the resource. Having the following work is NOT a requirement: a) start with no JCA b) With CLI /subsystem="jca":add() /subsystem="jca"/cached-connection-manager="cached-connection-manager":write-attribute(name=install,value=true) It's the parser that "auto-adds" the CCM resource, allowing you to do a write-attribute to the CCM. Here there is no parser involved so you have to add it before you can write-attribute. Making the above work would be possible via the step adding tricks I mentioned in my last post. But it's not really valid behavior and in a mixed version domain the legacy slaves wouldn't be able to handle it. So I don't think we should do it. Instead we should regard 1) working as being a bug, but one that we aren't fixing because fixing it might break people. [~maeste] Without objection I like to go ahead and implement it this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)