Is this related to JOPR-339?

I can reproduce the situation. The ServiceBindingManager is accessible via Profile services, BindingSets are also loaded. Problem must be in AS5 plugin.

I'm getting classcast exception org.rhq.plugins.jbossas5.serviceBinding.ManagerComponent cannot be cast to org.rhq.plugins.jbossas5.serviceBinding.ManagerComponent when running this code 

String bindingSetName = context.getParentResourceComponent().getBindingSetNameFromResourceKey(
            context.getResourceKey());
in SetComponent class. 

/ this exception is thrown when the server is started with params -b <addr> -c web when the server is started with params -b <addr> -c default everything works fine/

Parent resource of SetComponent is ServiceBindingManager which is singleton. 
SetComponents resources has for all EAP instances the same names(and keys) ports-01, ports-02, ports-03 and ports-default.

When the code from my previous comment is called current component classloader is classloader of ports-01 resource from "default" EAP server and the parent component classloader is ServiceBindingManager's resource classloader from "production" EAP server.

When I have two EAP servers in inventory and I call operation "Retrieve ClassLoader Information For All Resources" on Agent Plugin Container resource I have in the list of classloaders only one classloader for ports-01 etc..

It is the same for JBossWeb - Connectors components. When I have two eap servers :
./run.sh -b 10.0.0.253 -c default
./run.sh -b 10.0.0.253 -c production
connectors ajp://10.0.0.253:8009 and http://10.0.0.253:8080 are still Down (they have the same name for both instances, connectors with different names has separate classloaders). /there is again only one classloader/

looks like the canonical IDs used to identify a resource for knowing which classloader to use isn't as canonical as I thought :)

I looks like the "port-N" resources along with their singleton parents are not producing unique enough IDs used by the ClassLoaderManager. So it looks like the port-N resources for both EAP servers are resulting in the same hashcode lookup and thus one wins and the other loses (the loser resource gets the winner resource's classloader).

I'm gonna take this BZ and see if I can fix this. I know the code involved here.

the source of the problem I think is in the implementation of:

org.rhq.core.pc.plugin.CanonicalResourceKey

I was taking the resource keys of the resource itself and its parent, but we are down several levels deep and the parent key is that of the service binding manager resource which is a singleton and has a very basic key that is not unique across servers (which is fine, this is allowed - this canonical resource key stuff just doesn't take this into account)

i believe this problem was introduced when the fix to bug 551056 went in

release-3.0.0 branch commit: 0cb1c2429d8315e98d1ca264c51d06877159722e

needed to get that CanonicaResourceKey class look up the entire hierarchy, rather than just one level up (the direct parent). This now works on my box.

How to replicate:

1) Start two instances of EAP 5.0.1
2) Start agent and import both EAP instances
3) Confirm the Service Binding Manager and their children for both EAP instances are green (aka UP)

QA Verified.

Mass-closure of verified bugs against JON.

This fix is included in the RHQ branch used for EAP 5.1.x admin-console releases.