Re: [wildfly-dev] read-resource (even with include-runtime=false) iterates over dynamic children

I know that internally it’s useful in a number of places to know what children a resource has even without knowing their details beyond their address. If it’s useful internally it seems like it could be useful to outside callers too. I don’t know if HAL uses it. Removing that data would be a breaking change in our responses. Perhaps we could consider it for the :read-resource(include-runtime=false) case since the user has explicitly said they want things excluded, but for non-recursive :read-resource() (i.e. include-runtime=true) that would be a bigger problem with no way for users to get the data without using recursive=true. Regardless of that, having management resources represent remote objects is problematic for JMX. All management resources, dynamic or not, are available via JMX. MBeanServerConnection.getMBeanCount() and various uses of queryNames and queryMBeans with ObjectName patterns as the param result in needing to access all these resources. I can’t find any JMX API that would make it easy for users to say “except the runtime-only ones” plus I think some users wouldn’t be interested in that kind of thing anyway. I’ve heard of general purpose agent tools that do this kind of thing. One thought I had as I wrote this is perhaps marking the resources as remote may help. I don’t believe we expose remote resources via JMX, and if we do that sounds like a bug. Up to now, ‘remote’ has been used for the resource for other WF processes in a managed domain, but perhaps the use of the concept could be expanded. So, we should look into ‘remote’ and maybe all this goes away. :) If that doesnt’ pan out, I question why these things need to be modeled as resources. AFAICT they have no attributes and are just addresses against which operations can be executed. I don’t see much benefit in: /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity vs /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser) or /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true) vs /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true) Modeling these as resources allows you to list the identities etc via things like read-resource, read-children-names, etc but that’s both a feature and a bug. ;) A list-identities op on the realm accomplishes much the same thing. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat