On Jan 21, 2015, at 3:04 PM, Heiko Braun <hbraun@redhat.com> wrote:
Some additional information regarding the wildfly integration and the rest interface in particular:
Any subsystem in wildfly can register an undertow HTTP handler or an undertow HTTP upgrade handler. The HTTP handler exposes the regular undertow API for building HTTP based endpoints [1]. This one should be straight forward to use for implementing the REST interface you currently have in rhq-metrics.
The upgrade handler on the other hand does HTTP upgrade to a custom protocol of your choice (if needed in the future). It can as well be used to provide web socket based access to your services.
Taking into consideration that undertow can also be easily embedded [2] I think this covers a lot of ground.
Regards, Heiko
Thanks for the info Heiko. Here is what we need to figure out. Provided that all of the business logic resides in the core service, would the amount of work involved with building another implementation with undertow be small enough that it would be worth have the two implementations. If the amount of work is small, would this be something you (and by you I basically mean the WF team) would be comfortable owning?
One thing that comes to mind is the keycloak integration. I am not how much effort/duplication would be involved. If it does look like it will be a lot of effort and/or duplication, then we really need to consider a more minimal stack without JAX-RS.
I have another, somewhat related question. The LiveOak project is also working with hawkular-metrics. I think that they are deploying the metrics war side by side with their stuff. If we wind up with a more minimal implementation as you describe, how would that work with LiveOak which is ok with consuming a war since they are running in a server that already has war deployments, JAX-RS, etc.?
- John