On Jan 15, 2015, at 7:56 AM, John Sanda <jsanda@redhat.com> wrote:


On Jan 15, 2015, at 4:18 AM, Thomas Segismont <tsegismo@redhat.com> wrote:

Le 14/01/2015 17:18, John Sanda a écrit :
As for the UI and JAX-RS dependency, undertow is available in WF core,
and it supports servlets and web sockets out of the box right? To
eliminate the JAX-RS dependency, couldn’t we either 1) implement the
REST endpoints directly in servlet code ourselves or 2) expose a web
sockets API that the UI uses? My preference would be web sockets instead
of trying to implement a bunch of stuff that we get with JAX-RS.

If we need websockets for the console then let's add it. But that shouldn't be a reason to abandon the RESTful API.

That doesn't mean we need to stick to JAX-RS. But then we would have to write code or integrate libraries  which provides the things we use from the spec (please reply if I forgot or misrepresented something) :
* routing
* parameter binding
* content negotiation (selecting a method to handle the request and serializing the result in the appropriate format)

Also JAX-RS allows for an annotation-based swagger integration.

Eventually, we need to consider the impact on integration with KC.

I'll think more about this and will come back with a plan, if you agree.

I was not suggesting that we abandon the REST API. We still want the REST API for the stand alone metrics service. I am suggesting that we consider websockets for the embedded WF use case. Specifically, I am suggesting websockets using only undertow core and not pulling in additional dependencies.

This thread precipitated some conversations off list with Heiko Braun about wildfly-cassandra[1], wildfly-monitor[2], and the overall integration of rhq-metrics in WildFly. Here is a brief summary.

Any server that wants to be monitored will run wildfly-monitor. rhq-metrics and/or Cassandra could be co-located or run in their own dedicated vm’s, possibly even outside the topology (hosted offering). This means that wildfly-monitor will require some form of inter-process communication with rhq-metrics.

wildfly-cassandra can potentially run on any server, including domain and host controllers. For production scenarios though, it it more likely that Cassandra would run in its own dedicated VM. Regardless of how/where Cassandra is run, the metrics functionality needs to exist in both scenarios out of the box.

With respect to standalone mode, embedded Cassandra, and the in-memory data store, the preference is to use wildfly-cassandra in order to provide the same experience for both standalone and domain modes. If we run into challenges with start up time or anything else related to embedding Cassandra, we will assess and determine the best course of action.

The big problem with integrating rhq-metrics UI into the management console is the dependency on JAX-RS. Other AngularJS applications are already integrated into the console, so AngularJS itself should not be an issue. Iframes or Application Switcher might be options for integrating the UI bits.

I previously mentioned a websockets API in this thread for a couple reasons. Undertow core, which is in WF Core, provides websockets support. I was thinking that we pretty much need to look at what WF Core provides and work with that. Undertow is a full blown HTTP server, so we could still implement REST endpoints. It just doesn’t seem to make a lot of sense to reimplement a lot of the logic we already get with JAX-RS. Hence my suggestion for websockets. 

Let me reiterate to be clear, I am not proposing that we get rid of the REST API. I am only thinking about the embedded WF use case, which could very well be applicable to other embedding scenarios. In terms of integration, it is better to approach it as follows. rhq-metrics request a socket binding from WF and does what it needs to. This opens up the possibility to Netty for example, which has no external dependencies (Other than the JRE) and offers a lot more in terms of protocols than Undertow core.

[1] https://github.com/rhq-project/wildfly-cassandra
[2] https://github.com/rhq-project/wildfly-monitor