Bug 960292

Summary: Adding security-domain in domain mode can result in JBAS014884: No operation named 'composite' exists at address
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Tomaz Cerar <tcerar>
Component: Domain Management, SecurityAssignee: Brian Stansberry <brian.stansberry>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1.0CC: jcacek, mharvey, myarboro
Target Milestone: ER7   
Target Release: EAP 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomaz Cerar 2013-05-06 22:20:32 UTC
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.

Comment 1 Brian Stansberry 2013-05-06 22:27:30 UTC
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.

Comment 3 Brian Stansberry 2013-05-06 23:01:06 UTC
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.

Comment 8 Josef Cacek 2013-05-10 07:47:12 UTC
Verified in 6.1.0.ER8