read-resource (even with include-runtime=false) iterates over dynamic children

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

read-resource (even with include-runtime=false) iterates over dynamic children

Jan Kalina
Hi,
I am just checking how wildfly controller handle dynamic resources because
issue (WFCORE-2691) where every recursive :read-resource (even with
include-runtime=false) asks parent resource for list of all dynamic (runtime only)
children.

For example query:
/subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
will cause "server" resource (child of messaging-activemq) is asked for list
of all "core-address" (call getChildren("core-address")), even trough they are not
displayed as part of operation result - only blank placeholder is printed:
"core-address" => undefined,

This is problem especially in case of new Elytron resources which allow to browse
user identities using AS model - every :read-resource on root or every AS boot
currently causes iterating over all users/identities available in all concerned realms.

Is this design problem?
Is there some reason why should wildfly controller ask for all resource children
even when they are ignored and not printed?
What do you think about it? How should be resources with dynamic children handled?

Thanks,
Honza

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry
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.


> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]> wrote:
>
> Hi,
> I am just checking how wildfly controller handle dynamic resources because
> issue (WFCORE-2691) where every recursive :read-resource (even with
> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
> children.
>
> For example query:
> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
> will cause "server" resource (child of messaging-activemq) is asked for list
> of all "core-address" (call getChildren("core-address")), even trough they are not
> displayed as part of operation result - only blank placeholder is printed:
> "core-address" => undefined,
>
> This is problem especially in case of new Elytron resources which allow to browse
> user identities using AS model - every :read-resource on root or every AS boot
> currently causes iterating over all users/identities available in all concerned realms.
>
> Is this design problem?
> Is there some reason why should wildfly controller ask for all resource children
> even when they are ignored and not printed?
> What do you think about it? How should be resources with dynamic children handled?
>
> Thanks,
> Honza
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry

> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <[hidden email]> wrote:
>
> 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. :)

I poked a bit and while this may be an interesting thing to explore some day it’s not something practical for WF 11. The handling of ‘remote’ resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It’s not something applicable to other sorts of usage.

>
> 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.
>
>
>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]> wrote:
>>
>> Hi,
>> I am just checking how wildfly controller handle dynamic resources because
>> issue (WFCORE-2691) where every recursive :read-resource (even with
>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>> children.
>>
>> For example query:
>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>> will cause "server" resource (child of messaging-activemq) is asked for list
>> of all "core-address" (call getChildren("core-address")), even trough they are not
>> displayed as part of operation result - only blank placeholder is printed:
>> "core-address" => undefined,
>>
>> This is problem especially in case of new Elytron resources which allow to browse
>> user identities using AS model - every :read-resource on root or every AS boot
>> currently causes iterating over all users/identities available in all concerned realms.
>>
>> Is this design problem?
>> Is there some reason why should wildfly controller ask for all resource children
>> even when they are ignored and not printed?
>> What do you think about it? How should be resources with dynamic children handled?
>>
>> Thanks,
>> Honza
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jan Kalina
Not sure if it helps for JMX, but at least for management I see the core of the problem in obtaining
children of node even through there is placeholder pushed into the operation result...
It is something for which I dont see any reason - this should be possible to fix even without management behaviour change.

Not experienced in JMX, but are not the same placeholders used here too? (if yes, it could be the same problem...)


On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <[hidden email]> wrote:

> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <[hidden email]> wrote:
>
> 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. :)

I poked a bit and while this may be an interesting thing to explore some day it’s not something practical for WF 11. The handling of ‘remote’ resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It’s not something applicable to other sorts of usage.

>
> 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.
>
>
>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]> wrote:
>>
>> Hi,
>> I am just checking how wildfly controller handle dynamic resources because
>> issue (WFCORE-2691) where every recursive :read-resource (even with
>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>> children.
>>
>> For example query:
>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>> will cause "server" resource (child of messaging-activemq) is asked for list
>> of all "core-address" (call getChildren("core-address")), even trough they are not
>> displayed as part of operation result - only blank placeholder is printed:
>> "core-address" => undefined,
>>
>> This is problem especially in case of new Elytron resources which allow to browse
>> user identities using AS model - every :read-resource on root or every AS boot
>> currently causes iterating over all users/identities available in all concerned realms.
>>
>> Is this design problem?
>> Is there some reason why should wildfly controller ask for all resource children
>> even when they are ignored and not printed?
>> What do you think about it? How should be resources with dynamic children handled?
>>
>> Thanks,
>> Honza
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

Mail Attachment (21 bytes) Download Attachment
encrypted.asc (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry
Here’s my last post again. For some reason my mail client decide to encrypt it when it resent it.

> On Apr 23, 2017, at 7:31 AM, Brian Stansberry <[hidden email]> wrote:
>
>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <[hidden email]> wrote:
>>
>> Not sure if it helps for JMX, but at least for management I see the core of the problem in obtaining
>> children of node even through there is placeholder pushed into the operation result...
>> It is something for which I dont see any reason - this should be possible to fix even without management behaviour change.
>>
>
> There is a placeholder per address. Even if we made the placeholder objects go away, we have a requirement to list the child addresses that cannot be made to go away. The critical cost here is identifying those addresses, more so than manipulating the placeholder objects. Identifying those addresses means making a remote call to an LDAP server and iterating over possibly thousands of results.
>
>> Not experienced in JMX, but are not the same placeholders used here too? (if yes, it could be the same problem…)
>>
>
> If we say an identity is a management resource, that means we can produce an mbean for it. And that means JMX ops like MBeanServer.getMBeanCount() need to access all of those resources, at a minimum to know their address.
>
> Why do these identities need to be represented as management resources?
>
>>
>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <[hidden email]> wrote:
>>
>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <[hidden email]> wrote:
>>>
>>> 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. :)
>>
>> I poked a bit and while this may be an interesting thing to explore some day it’s not something practical for WF 11. The handling of ‘remote’ resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It’s not something applicable to other sorts of usage.
>>
>>>
>>> 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.
>>>
>>>
>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>> I am just checking how wildfly controller handle dynamic resources because
>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>>>> children.
>>>>
>>>> For example query:
>>>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>> will cause "server" resource (child of messaging-activemq) is asked for list
>>>> of all "core-address" (call getChildren("core-address")), even trough they are not
>>>> displayed as part of operation result - only blank placeholder is printed:
>>>> "core-address" => undefined,
>>>>
>>>> This is problem especially in case of new Elytron resources which allow to browse
>>>> user identities using AS model - every :read-resource on root or every AS boot
>>>> currently causes iterating over all users/identities available in all concerned realms.
>>>>
>>>> Is this design problem?
>>>> Is there some reason why should wildfly controller ask for all resource children
>>>> even when they are ignored and not printed?
>>>> What do you think about it? How should be resources with dynamic children handled?
>>>>
>>>> Thanks,
>>>> Honza
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> JBoss by Red Hat
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jan Kalina
Darran, when consider mentioned problems (especially getting amount of all mbeans and other operations
on mbeans, where we cannot filter runtime only things out) do we have same reason to represent identities as resources?
(Using realm operations instead sounds reasonable.)

On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry <[hidden email]> wrote:
Here’s my last post again. For some reason my mail client decide to encrypt it when it resent it.

> On Apr 23, 2017, at 7:31 AM, Brian Stansberry <[hidden email]> wrote:
>
>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <[hidden email]> wrote:
>>
>> Not sure if it helps for JMX, but at least for management I see the core of the problem in obtaining
>> children of node even through there is placeholder pushed into the operation result...
>> It is something for which I dont see any reason - this should be possible to fix even without management behaviour change.
>>
>
> There is a placeholder per address. Even if we made the placeholder objects go away, we have a requirement to list the child addresses that cannot be made to go away. The critical cost here is identifying those addresses, more so than manipulating the placeholder objects. Identifying those addresses means making a remote call to an LDAP server and iterating over possibly thousands of results.
>
>> Not experienced in JMX, but are not the same placeholders used here too? (if yes, it could be the same problem…)
>>
>
> If we say an identity is a management resource, that means we can produce an mbean for it. And that means JMX ops like MBeanServer.getMBeanCount() need to access all of those resources, at a minimum to know their address.
>
> Why do these identities need to be represented as management resources?
>
>>
>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <[hidden email]> wrote:
>>
>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <[hidden email]> wrote:
>>>
>>> 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. :)
>>
>> I poked a bit and while this may be an interesting thing to explore some day it’s not something practical for WF 11. The handling of ‘remote’ resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It’s not something applicable to other sorts of usage.
>>
>>>
>>> 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.
>>>
>>>
>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>> I am just checking how wildfly controller handle dynamic resources because
>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>>>> children.
>>>>
>>>> For example query:
>>>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>> will cause "server" resource (child of messaging-activemq) is asked for list
>>>> of all "core-address" (call getChildren("core-address")), even trough they are not
>>>> displayed as part of operation result - only blank placeholder is printed:
>>>> "core-address" => undefined,
>>>>
>>>> This is problem especially in case of new Elytron resources which allow to browse
>>>> user identities using AS model - every :read-resource on root or every AS boot
>>>> currently causes iterating over all users/identities available in all concerned realms.
>>>>
>>>> Is this design problem?
>>>> Is there some reason why should wildfly controller ask for all resource children
>>>> even when they are ignored and not printed?
>>>> What do you think about it? How should be resources with dynamic children handled?
>>>>
>>>> Thanks,
>>>> Honza
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> JBoss by Red Hat
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Darran Lofthouse
Moving away from resources to operations may make more sense -
especially for realms with large a number of identities.

On 24/04/17 18:44, Jan Kalina wrote:

> Darran, when consider mentioned problems (especially getting amount of
> all mbeans and other operations
> on mbeans, where we cannot filter runtime only things out) do we have
> same reason to represent identities as resources?
> (Using realm operations instead sounds reasonable.)
>
> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Here’s my last post again. For some reason my mail client decide to
>     encrypt it when it resent it.
>
>     > On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>     >
>     >> On Apr 21, 2017, at 2:22 AM, Jan Kalina <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>
>     >> Not sure if it helps for JMX, but at least for management I see
>     the core of the problem in obtaining
>     >> children of node even through there is placeholder pushed into
>     the operation result...
>     >> It is something for which I dont see any reason - this should be
>     possible to fix even without management behaviour change.
>     >>
>     >
>     > There is a placeholder per address. Even if we made the
>     placeholder objects go away, we have a requirement to list the child
>     addresses that cannot be made to go away. The critical cost here is
>     identifying those addresses, more so than manipulating the
>     placeholder objects. Identifying those addresses means making a
>     remote call to an LDAP server and iterating over possibly thousands
>     of results.
>     >
>     >> Not experienced in JMX, but are not the same placeholders used
>     here too? (if yes, it could be the same problem…)
>     >>
>     >
>     > If we say an identity is a management resource, that means we can
>     produce an mbean for it. And that means JMX ops like
>     MBeanServer.getMBeanCount() need to access all of those resources,
>     at a minimum to know their address.
>     >
>     > Why do these identities need to be represented as management
>     resources?
>     >
>     >>
>     >> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>     >>
>     >>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>     >>>
>     >>> 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. :)
>     >>
>     >> I poked a bit and while this may be an interesting thing to
>     explore some day it’s not something practical for WF 11. The
>     handling of ‘remote’ resource types is based on their being no
>     Resource instances for them in the local resource tree, and then a
>     special ManagementResourceRegistration is registered for each
>     individual resource (/host=slave, /server=server-one etc) that
>     proxies any operations addressed to that specific resource to a
>     remote WildFly process. It’s not something applicable to other sorts
>     of usage.
>     >>
>     >>>
>     >>> 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.
>     >>>
>     >>>
>     >>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>>>
>     >>>> Hi,
>     >>>> I am just checking how wildfly controller handle dynamic
>     resources because
>     >>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>     >>>> include-runtime=false) asks parent resource for list of all
>     dynamic (runtime only)
>     >>>> children.
>     >>>>
>     >>>> For example query:
>     >>>>
>     /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>     >>>> will cause "server" resource (child of messaging-activemq) is
>     asked for list
>     >>>> of all "core-address" (call getChildren("core-address")), even
>     trough they are not
>     >>>> displayed as part of operation result - only blank placeholder
>     is printed:
>     >>>> "core-address" => undefined,
>     >>>>
>     >>>> This is problem especially in case of new Elytron resources
>     which allow to browse
>     >>>> user identities using AS model - every :read-resource on root
>     or every AS boot
>     >>>> currently causes iterating over all users/identities available
>     in all concerned realms.
>     >>>>
>     >>>> Is this design problem?
>     >>>> Is there some reason why should wildfly controller ask for all
>     resource children
>     >>>> even when they are ignored and not printed?
>     >>>> What do you think about it? How should be resources with
>     dynamic children handled?
>     >>>>
>     >>>> Thanks,
>     >>>> Honza
>     >>>> _______________________________________________
>     >>>> wildfly-dev mailing list
>     >>>> [hidden email] <mailto:[hidden email]>
>     >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >>>
>     >>> --
>     >>> Brian Stansberry
>     >>> Manager, Senior Principal Software Engineer
>     >>> JBoss by Red Hat
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> wildfly-dev mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >>
>     >> --
>     >> Brian Stansberry
>     >> Manager, Senior Principal Software Engineer
>     >> JBoss by Red Hat
>     >>
>     >>
>     >>
>     >>
>     >
>     > --
>     > Brian Stansberry
>     > Manager, Senior Principal Software Engineer
>     > JBoss by Red Hat
>
>     --
>     Brian Stansberry
>     Manager, Senior Principal Software Engineer
>     JBoss by Red Hat
>
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

David M. Lloyd
+1, in consideration of all the facts this seems like a better approach.

On 04/24/2017 12:54 PM, Darran Lofthouse wrote:

> Moving away from resources to operations may make more sense -
> especially for realms with large a number of identities.
>
> On 24/04/17 18:44, Jan Kalina wrote:
>> Darran, when consider mentioned problems (especially getting amount of
>> all mbeans and other operations
>> on mbeans, where we cannot filter runtime only things out) do we have
>> same reason to represent identities as resources?
>> (Using realm operations instead sounds reasonable.)
>>
>> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Here’s my last post again. For some reason my mail client decide to
>>     encrypt it when it resent it.
>>
>>     > On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>>     <[hidden email] <mailto:[hidden email]>>
>>     wrote:
>>     >
>>     >> On Apr 21, 2017, at 2:22 AM, Jan Kalina <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>     >>
>>     >> Not sure if it helps for JMX, but at least for management I see
>>     the core of the problem in obtaining
>>     >> children of node even through there is placeholder pushed into
>>     the operation result...
>>     >> It is something for which I dont see any reason - this should be
>>     possible to fix even without management behaviour change.
>>     >>
>>     >
>>     > There is a placeholder per address. Even if we made the
>>     placeholder objects go away, we have a requirement to list the child
>>     addresses that cannot be made to go away. The critical cost here is
>>     identifying those addresses, more so than manipulating the
>>     placeholder objects. Identifying those addresses means making a
>>     remote call to an LDAP server and iterating over possibly thousands
>>     of results.
>>     >
>>     >> Not experienced in JMX, but are not the same placeholders used
>>     here too? (if yes, it could be the same problem…)
>>     >>
>>     >
>>     > If we say an identity is a management resource, that means we can
>>     produce an mbean for it. And that means JMX ops like
>>     MBeanServer.getMBeanCount() need to access all of those resources,
>>     at a minimum to know their address.
>>     >
>>     > Why do these identities need to be represented as management
>>     resources?
>>     >
>>     >>
>>     >> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>>     <[hidden email] <mailto:[hidden email]>>
>>     wrote:
>>     >>
>>     >>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>>     <[hidden email] <mailto:[hidden email]>>
>>     wrote:
>>     >>>
>>     >>> 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. :)
>>     >>
>>     >> I poked a bit and while this may be an interesting thing to
>>     explore some day it’s not something practical for WF 11. The
>>     handling of ‘remote’ resource types is based on their being no
>>     Resource instances for them in the local resource tree, and then a
>>     special ManagementResourceRegistration is registered for each
>>     individual resource (/host=slave, /server=server-one etc) that
>>     proxies any operations addressed to that specific resource to a
>>     remote WildFly process. It’s not something applicable to other sorts
>>     of usage.
>>     >>
>>     >>>
>>     >>> 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.
>>     >>>
>>     >>>
>>     >>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>     >>>>
>>     >>>> Hi,
>>     >>>> I am just checking how wildfly controller handle dynamic
>>     resources because
>>     >>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>     >>>> include-runtime=false) asks parent resource for list of all
>>     dynamic (runtime only)
>>     >>>> children.
>>     >>>>
>>     >>>> For example query:
>>     >>>>
>>     /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>     >>>> will cause "server" resource (child of messaging-activemq) is
>>     asked for list
>>     >>>> of all "core-address" (call getChildren("core-address")), even
>>     trough they are not
>>     >>>> displayed as part of operation result - only blank placeholder
>>     is printed:
>>     >>>> "core-address" => undefined,
>>     >>>>
>>     >>>> This is problem especially in case of new Elytron resources
>>     which allow to browse
>>     >>>> user identities using AS model - every :read-resource on root
>>     or every AS boot
>>     >>>> currently causes iterating over all users/identities available
>>     in all concerned realms.
>>     >>>>
>>     >>>> Is this design problem?
>>     >>>> Is there some reason why should wildfly controller ask for all
>>     resource children
>>     >>>> even when they are ignored and not printed?
>>     >>>> What do you think about it? How should be resources with
>>     dynamic children handled?
>>     >>>>
>>     >>>> Thanks,
>>     >>>> Honza
>>     >>>> _______________________________________________
>>     >>>> wildfly-dev mailing list
>>     >>>> [hidden email] <mailto:[hidden email]>
>>     >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>     >>>
>>     >>> --
>>     >>> Brian Stansberry
>>     >>> Manager, Senior Principal Software Engineer
>>     >>> JBoss by Red Hat
>>     >>>
>>     >>>
>>     >>>
>>     >>>
>>     >>> _______________________________________________
>>     >>> wildfly-dev mailing list
>>     >>> [hidden email] <mailto:[hidden email]>
>>     >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>     >>
>>     >> --
>>     >> Brian Stansberry
>>     >> Manager, Senior Principal Software Engineer
>>     >> JBoss by Red Hat
>>     >>
>>     >>
>>     >>
>>     >>
>>     >
>>     > --
>>     > Brian Stansberry
>>     > Manager, Senior Principal Software Engineer
>>     > JBoss by Red Hat
>>
>>     --
>>     Brian Stansberry
>>     Manager, Senior Principal Software Engineer
>>     JBoss by Red Hat
>>
>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Brian Stansberry
I agree.

The kernel can be better about the JMX stuff I think, but some cases like MBeanServer.getMBeanCount() mean there’s no alternative to identifying every resource. But for some less extreme cases we can be better I think by avoiding the unknown-cost runtime-only resources and just dealing with the known-cost ManagementResourceRegistration data. I filed a JIRA for that:

https://issues.jboss.org/browse/WFCORE-2719

> On Apr 24, 2017, at 1:20 PM, David M. Lloyd <[hidden email]> wrote:
>
> +1, in consideration of all the facts this seems like a better approach.
>
> On 04/24/2017 12:54 PM, Darran Lofthouse wrote:
>> Moving away from resources to operations may make more sense -
>> especially for realms with large a number of identities.
>>
>> On 24/04/17 18:44, Jan Kalina wrote:
>>> Darran, when consider mentioned problems (especially getting amount of
>>> all mbeans and other operations
>>> on mbeans, where we cannot filter runtime only things out) do we have
>>> same reason to represent identities as resources?
>>> (Using realm operations instead sounds reasonable.)
>>>
>>> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>    Here’s my last post again. For some reason my mail client decide to
>>>    encrypt it when it resent it.
>>>
>>>> On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>>>    <[hidden email] <mailto:[hidden email]>>
>>>    wrote:
>>>>
>>>>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <[hidden email]
>>>    <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Not sure if it helps for JMX, but at least for management I see
>>>    the core of the problem in obtaining
>>>>> children of node even through there is placeholder pushed into
>>>    the operation result...
>>>>> It is something for which I dont see any reason - this should be
>>>    possible to fix even without management behaviour change.
>>>>>
>>>>
>>>> There is a placeholder per address. Even if we made the
>>>    placeholder objects go away, we have a requirement to list the child
>>>    addresses that cannot be made to go away. The critical cost here is
>>>    identifying those addresses, more so than manipulating the
>>>    placeholder objects. Identifying those addresses means making a
>>>    remote call to an LDAP server and iterating over possibly thousands
>>>    of results.
>>>>
>>>>> Not experienced in JMX, but are not the same placeholders used
>>>    here too? (if yes, it could be the same problem…)
>>>>>
>>>>
>>>> If we say an identity is a management resource, that means we can
>>>    produce an mbean for it. And that means JMX ops like
>>>    MBeanServer.getMBeanCount() need to access all of those resources,
>>>    at a minimum to know their address.
>>>>
>>>> Why do these identities need to be represented as management
>>>    resources?
>>>>
>>>>>
>>>>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>>>    <[hidden email] <mailto:[hidden email]>>
>>>    wrote:
>>>>>
>>>>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>>>    <[hidden email] <mailto:[hidden email]>>
>>>    wrote:
>>>>>>
>>>>>> 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. :)
>>>>>
>>>>> I poked a bit and while this may be an interesting thing to
>>>    explore some day it’s not something practical for WF 11. The
>>>    handling of ‘remote’ resource types is based on their being no
>>>    Resource instances for them in the local resource tree, and then a
>>>    special ManagementResourceRegistration is registered for each
>>>    individual resource (/host=slave, /server=server-one etc) that
>>>    proxies any operations addressed to that specific resource to a
>>>    remote WildFly process. It’s not something applicable to other sorts
>>>    of usage.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <[hidden email]
>>>    <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> I am just checking how wildfly controller handle dynamic
>>>    resources because
>>>>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>>>>> include-runtime=false) asks parent resource for list of all
>>>    dynamic (runtime only)
>>>>>>> children.
>>>>>>>
>>>>>>> For example query:
>>>>>>>
>>>    /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>>>>> will cause "server" resource (child of messaging-activemq) is
>>>    asked for list
>>>>>>> of all "core-address" (call getChildren("core-address")), even
>>>    trough they are not
>>>>>>> displayed as part of operation result - only blank placeholder
>>>    is printed:
>>>>>>> "core-address" => undefined,
>>>>>>>
>>>>>>> This is problem especially in case of new Elytron resources
>>>    which allow to browse
>>>>>>> user identities using AS model - every :read-resource on root
>>>    or every AS boot
>>>>>>> currently causes iterating over all users/identities available
>>>    in all concerned realms.
>>>>>>>
>>>>>>> Is this design problem?
>>>>>>> Is there some reason why should wildfly controller ask for all
>>>    resource children
>>>>>>> even when they are ignored and not printed?
>>>>>>> What do you think about it? How should be resources with
>>>    dynamic children handled?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Honza
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>    <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> JBoss by Red Hat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>    <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>
>>>    --
>>>    Brian Stansberry
>>>    Manager, Senior Principal Software Engineer
>>>    JBoss by Red Hat
>>>
>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev