[wildfly-dev] 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 <
brian.stansberry at redhat.com> wrote:

>
> > On Apr 20, 2017, at 12:22 PM, Brian Stansberry <
> brian.stansberry at redhat.com> 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 <jkalina at redhat.com> 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
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Brian Stansberry
> > Manager, Senior Principal Software Engineer
> > JBoss by Red Hat
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170421/8fcb19be/attachment-0001.html