Improve query() operation for complex attributes?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Improve query() operation for complex attributes?

Lin Gao
Hi,

  Each management resource has an operation named 'query()' to filter resources according to the condition passed by 'selector' and 'where' parameters, however it does not work for complex attributes.

  2 example of complex attributes:

     - 'query()' operation cannot find which 'possible-capabilities' provides the capability with name 'org.wildfly.data-source'
     - It cannot find which 'rest-resource-paths' provides the REST endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment either.

  Especially for the second case in above examples, it will be helpful for users when doing troubleshooting in case of large deployment.

  Actually, it does not limit to the complex attributes, it would be good to be able to filter resources by condition specified by attribute value of nested child resources(not only by the first level of child resource).

  WDYT?

Best Regards

--
Lin Gao
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
|  
Report Content as Inappropriate

Re: Improve query() operation for complex attributes?

James Perkins
The second case worked for me without an issue.
[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"])
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("deployment" => "batch-chunk.war"),
            ("subsystem" => "jaxrs"),
            ("rest-resource" => "org.jboss.example.batch.rest.BatchResource")
        ],
        "outcome" => "success",
        "result" => {"rest-resource-paths" => [
            {
                "resource-path" => "batch/jobs",
                "consumes" => undefined,
                "produces" => ["application/json"],
                "java-method" => "javax.ws.rs.core.Response org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
                "resource-methods" => ["GET /batch-chunk/rest/batch/jobs"]
            },
            {
                "resource-path" => "batch/jobs/{status}",
                "consumes" => undefined,
                "produces" => ["application/json"],
                "java-method" => "javax.ws.rs.core.Response org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam java.lang.String status)",
                "resource-methods" => ["GET /batch-chunk/rest/batch/jobs/{status}"]
            }
        ]}
    }]
}

The read-resource operation really does the same thing though in this case.

On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <[hidden email]> wrote:
Hi,

  Each management resource has an operation named 'query()' to filter resources according to the condition passed by 'selector' and 'where' parameters, however it does not work for complex attributes.

  2 example of complex attributes:

     - 'query()' operation cannot find which 'possible-capabilities' provides the capability with name 'org.wildfly.data-source'
     - It cannot find which 'rest-resource-paths' provides the REST endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment either.

  Especially for the second case in above examples, it will be helpful for users when doing troubleshooting in case of large deployment.

  Actually, it does not limit to the complex attributes, it would be good to be able to filter resources by condition specified by attribute value of nested child resources(not only by the first level of child resource).

  WDYT?

Best Regards

--
Lin Gao
Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
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
|  
Report Content as Inappropriate

Re: Improve query() operation for complex attributes?

Lin Gao
----- Original Message -----

> From: "James Perkins" <[hidden email]>
> To: "Lin Gao" <[hidden email]>
> Cc: [hidden email]
> Sent: Wednesday, November 23, 2016 6:11:21 AM
> Subject: Re: [wildfly-dev] Improve query() operation for complex attributes?
>
> The second case worked for me without an issue.
> [standalone@localhost:9990 /]
> /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"])
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("deployment" => "batch-chunk.war"),
>             ("subsystem" => "jaxrs"),
>             ("rest-resource" =>
> "org.jboss.example.batch.rest.BatchResource")
>         ],
>         "outcome" => "success",
>         "result" => {"rest-resource-paths" => [
>             {
>                 "resource-path" => "batch/jobs",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
>                 "resource-methods" => ["GET /batch-chunk/rest/batch/jobs"]
>             },
>             {
>                 "resource-path" => "batch/jobs/{status}",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam
> java.lang.String status)",
>                 "resource-methods" => ["GET
> /batch-chunk/rest/batch/jobs/{status}"]
>             }
>         ]}
>     }]
> }

You just listed all 'rest-resource-paths' without any filtering, if you have over 100 REST endpoints in 'batch-chunk.war', it will be difficult to find the one which provides "resource-path" => "batch/jobs".

Let's assume the following command can do the task:

[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})

here the 'rest-resource-paths.resource-path' is the attribute name in enhanced syntax.

> The read-resource operation really does the same thing though in this case.

Yes, it does, but I think the most important feature provided by 'query()' operation is that it can filter resources by conditions specified by 'where' parameter.

It works only on simple attributes, like:

[standalone@localhost:9990 /] /subsystem=datasources/jdbc-driver=*:query(select=[driver-xa-datasource-class-name], where={driver-name=h2})
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("subsystem" => "datasources"),
            ("jdbc-driver" => "h2")
        ],
        "outcome" => "success",
        "result" => {"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"}
    }]
}

It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are inside the complex attribute, so that the following commands can work:

[standalone@localhost:9990 /] /core-service=capability-registry:query(select=[possible-capabilities],where={possible-capabilities.name=org.wildfly.data-source})

[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})



Best Regards
--
Lin Gao
Software Engineer
JBoss by Red Hat
 

> On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <[hidden email]> wrote:
>
> > Hi,
> >
> >   Each management resource has an operation named 'query()' to filter
> > resources according to the condition passed by 'selector' and 'where'
> > parameters, however it does not work for complex attributes.
> >
> >   2 example of complex attributes:
> >
> >      - 'query()' operation cannot find which 'possible-capabilities'
> > provides the capability with name 'org.wildfly.data-source'
> >      - It cannot find which 'rest-resource-paths' provides the REST
> > endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment
> > either.
> >
> >   Especially for the second case in above examples, it will be helpful for
> > users when doing troubleshooting in case of large deployment.
> >
> >   Actually, it does not limit to the complex attributes, it would be good
> > to be able to filter resources by condition specified by attribute value of
> > nested child resources(not only by the first level of child resource).
> >
> >   WDYT?
> >
> > Best Regards
> >
> > --
> > Lin Gao
> > Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
>
> --
> James R. Perkins
> 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
|  
Report Content as Inappropriate

Re: Improve query() operation for complex attributes?

James Perkins
Ah, I see. Sorry for the confusion. It might be possible with that dot notation. You could file a JIRA and someone can look at it when there is time. It does seem possible though.

On Tue, Nov 22, 2016 at 5:39 PM, Lin Gao <[hidden email]> wrote:
----- Original Message -----
> From: "James Perkins" <[hidden email]>
> To: "Lin Gao" <[hidden email]>
> Cc: [hidden email]
> Sent: Wednesday, November 23, 2016 6:11:21 AM
> Subject: Re: [wildfly-dev] Improve query() operation for complex attributes?
>
> The second case worked for me without an issue.
> [standalone@localhost:9990 /]
> /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"])
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("deployment" => "batch-chunk.war"),
>             ("subsystem" => "jaxrs"),
>             ("rest-resource" =>
> "org.jboss.example.batch.rest.BatchResource")
>         ],
>         "outcome" => "success",
>         "result" => {"rest-resource-paths" => [
>             {
>                 "resource-path" => "batch/jobs",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
>                 "resource-methods" => ["GET /batch-chunk/rest/batch/jobs"]
>             },
>             {
>                 "resource-path" => "batch/jobs/{status}",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam
> java.lang.String status)",
>                 "resource-methods" => ["GET
> /batch-chunk/rest/batch/jobs/{status}"]
>             }
>         ]}
>     }]
> }

You just listed all 'rest-resource-paths' without any filtering, if you have over 100 REST endpoints in 'batch-chunk.war', it will be difficult to find the one which provides "resource-path" => "batch/jobs".

Let's assume the following command can do the task:

[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})

here the 'rest-resource-paths.resource-path' is the attribute name in enhanced syntax.

> The read-resource operation really does the same thing though in this case.

Yes, it does, but I think the most important feature provided by 'query()' operation is that it can filter resources by conditions specified by 'where' parameter.

It works only on simple attributes, like:

[standalone@localhost:9990 /] /subsystem=datasources/jdbc-driver=*:query(select=[driver-xa-datasource-class-name], where={driver-name=h2})
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("subsystem" => "datasources"),
            ("jdbc-driver" => "h2")
        ],
        "outcome" => "success",
        "result" => {"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"}
    }]
}

It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are inside the complex attribute, so that the following commands can work:

[standalone@localhost:9990 /] /core-service=capability-registry:query(select=[possible-capabilities],where={possible-capabilities.name=org.wildfly.data-source})

[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})



Best Regards
--
Lin Gao
Software Engineer
JBoss by Red Hat

> On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <[hidden email]> wrote:
>
> > Hi,
> >
> >   Each management resource has an operation named 'query()' to filter
> > resources according to the condition passed by 'selector' and 'where'
> > parameters, however it does not work for complex attributes.
> >
> >   2 example of complex attributes:
> >
> >      - 'query()' operation cannot find which 'possible-capabilities'
> > provides the capability with name 'org.wildfly.data-source'
> >      - It cannot find which 'rest-resource-paths' provides the REST
> > endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment
> > either.
> >
> >   Especially for the second case in above examples, it will be helpful for
> > users when doing troubleshooting in case of large deployment.
> >
> >   Actually, it does not limit to the complex attributes, it would be good
> > to be able to filter resources by condition specified by attribute value of
> > nested child resources(not only by the first level of child resource).
> >
> >   WDYT?
> >
> > Best Regards
> >
> > --
> > Lin Gao
> > Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>



--
James R. Perkins
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
|  
Report Content as Inappropriate

Re: Improve query() operation for complex attributes?

Tomaž Cerar-2

On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <[hidden email]> wrote:
Ah, I see. Sorry for the confusion. It might be possible with that dot notation. You could file a JIRA and someone can look at it when there is time. It does seem possible though.


As long as query op uses :read-attribute / :read-resource for its work than dot notation should work just fine



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

Re: Improve query() operation for complex attributes?

Brian Stansberry

> On Nov 23, 2016, at 10:33 AM, Tomaž Cerar <[hidden email]> wrote:
>
>
> On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <[hidden email]> wrote:
> Ah, I see. Sorry for the confusion. It might be possible with that dot notation. You could file a JIRA and someone can look at it when there is time. It does seem possible though.
>
>
> As long as query op uses :read-attribute / :read-resource for its work than dot notation should work just fine
>

It doesn’t.

WFCORE RFE Jiras for this should probably be split in two, as the request for dealing with child resources is significantly more complex. The dot notation isn’t currently applied to children anywhere.

> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Improve query() operation for complex attributes?

Lin Gao
----- Original Message -----

> From: "Brian Stansberry" <[hidden email]>
> To: "Tomaž Cerar" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, November 24, 2016 12:50:29 AM
> Subject: Re: [wildfly-dev] Improve query() operation for complex attributes?
>
>
> > On Nov 23, 2016, at 10:33 AM, Tomaž Cerar <[hidden email]> wrote:
> >
> >
> > On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <[hidden email]> wrote:
> > Ah, I see. Sorry for the confusion. It might be possible with that dot
> > notation. You could file a JIRA and someone can look at it when there is
> > time. It does seem possible though.
> >
> >
> > As long as query op uses :read-attribute / :read-resource for its work than
> > dot notation should work just fine
> >
>
> It doesn’t.
>
> WFCORE RFE Jiras for this should probably be split in two, as the request for
> dealing with child resources is significantly more complex. The dot notation
> isn’t currently applied to children anywhere.

https://issues.jboss.org/browse/WFCORE-2041 is created for improvement of query in complex attributes
https://issues.jboss.org/browse/WFCORE-2042 is created for improvement of query in nested child resources

The dot notation should apply for attribute names[1], if the dot does not work for resource names,
maybe another parameter like: 'separator' can be added to query() operation to specify one.


[1] https://lists.jboss.org/pipermail/hawkular-dev/2015-June/001158.html

Best Regards
--
Lin Gao
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

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