<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jan 21, 2015, at 3:04 PM, Heiko Braun <<a href="mailto:hbraun@redhat.com" class="">hbraun@redhat.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Some additional information regarding the wildfly integration and the rest interface in particular:<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Taking into consideration that undertow can also be easily embedded [2] I think this covers a lot of ground.</div><div class=""><br class=""></div><div class="">Regards, Heiko</div><div class=""><br class=""></div><div class="">[1] <a href="http://undertow.io/documentation/core/undertow-handler-guide.html" class="">http://undertow.io/documentation/core/undertow-handler-guide.html</a></div><div class="">[2] <a href="http://undertow.io/documentation/core/bootstrapping.html" class="">http://undertow.io/documentation/core/bootstrapping.html</a></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.?</div><div class=""><br class=""></div><div class="">- John</div></body></html>