Description of problem: certain add commands under security-domain fail with No operation named 'composite' exists at address even if there is no composite operation being used. Steps to Reproduce: /server-group=main-server-group:write-attribute(name=profile, value=ha) /server-group=main-server-group:write-attribute(name=socket-binding-group, value=ha-sockets) /profile=ha/subsystem=security/security-domain=teiid-security/authentication=classic:add /profile=ha/subsystem=security/security-domain=teiid-security/authentication=classic/login-module=UsersRolesLoginModule:add(code=org.jboss.security.auth.spi.UsersRolesLoginModule, flag=required, module-options=[("usersProperties"=>"$ {jboss.domain.config.dir}/teiid-security-users.properties"), ("rolesProperties"=>"${jboss.domain.config.dir} /teiid-security-roles.properties")]) Actual results: login-module add fails Expected results: succeeds Additional info: Problem only occurs in domain mode, standalone is ok. Investigation showed that problem is two part, first is that one transformer is buggy. and second more important is that transfomrers should not even been fired as all host controllers are same version.
The "second more important is that transfomrers should not even been fired as all host controllers are same version" bit is the more critical aspect of this. When a slave HC registers with the master, or when a server registers with its HC it is dropping the micro- part of it's management API version, so Infinispan 1.4.1 -> 1.4.0 Datasources 1.1.2 -> 1.1.0 EJB3 1.2.1 -> 1.2.0 Messaging 1.2.1 -> 1.2.0 Security 1.2.1 -> 1.2.0 I'll have to dig a bit to see the effect of that. It may not be so bad, because the master will see the slave as lower version and will transform to that and for a micro version that transformation should not require loss of functionality; i.e. it shouldn't involve stuff like some new API that can't be transformed.
Impact analysis of the issue described in my last comment: Infinispan 1.4.1 -> 1.4.0: No negative impact. If the legacy "virtual-nodes" attribute is used, it will get transformed to "segments". This would happen on the slave side anyway. Datasources 1.1.2 -> 1.1.0 No negative impact; API changes in 1.1.1 and 1.1.2 were to add missing API description metadata EJB3 1.2.1 -> 1.2.0: No negative impact; API change was related to runtime resources in the deployment tree and transformation is not relevant. Messaging 1.2.1 -> 1.2.0: Might result in some unnecessary WARN messages in the logs if the user uses the nonfunctional "clustered" attribute but declares a value that is inconsistent with the rest of the configuration. This would be an edge case and a misconfiguration anyway. Security 1.2.1 -> 1.2.0: This will result in the fix for the security subsystem aspect of https://bugzilla.redhat.com/show_bug.cgi?id=908714 not working (see https://issues.jboss.org/browse/WFLY-108 for a less cluttered description of the security subsystem issue). The "two part, first is that one transformer is buggy" bit that Tomaz mentioned is the cause of this not working; if not for that it would be fine. Other extensions: Other extensions not part of the EAP code base (i.e. layered product extensions or end user developed extensions) may have problems, although IMO this is unlikely. So, it seems the "second more important is that transfomrers should not even been fired as all host controllers are same version" aspect of this report is not that critical an issue. The security subsystem part may result in CLI scripts written against EAP 6.0.x not working because the bz 908714 fix is broken, but there is a workaround to this problem; simply adapt the scripts to the EAP 6.1 variant of the API.
Verified in 6.1.0.ER8