[Hawkular-dev] embedding hawkular-metrics

[John Sanda]

> On Jan 20, 2015, at 2:03 PM, Thomas Heute <theute at redhat.com> wrote:
> 
> 
> On 01/20/2015 05:35 PM, John Sanda wrote:
>> We already know from previous discussions that one of the use cases for metrics is embedding. There have been plenty of discussions with the WildFly team, notably with Heiko Braun, as well as discussions with the Fabric8 team about embedding metrics into their respective platforms. It has already been established that the dependency on JAX-RS prevents embedding the metrics UI components into the WildFly management console. Do we want to have a different, alternative stack for the embedded use case? An alternative stack would of course *not* depend on JAX-RS. It would maintain a smaller set of dependencies, and maybe more importantly it would require less and not more components/services from WildFly.
>> 
>> I like the idea of a small stack with minimal dependencies, but I do not necessarily like the idea of maintaining one stack for embedded and another stack for other use cases. In other words, I do not want to maintain two implementations of the REST endpoints.
> 2 definitely sounds bad, what option do we have to maintain a unique one for both usecases ?
> 

One option could be undertow core + json parser. I have not investigated enough to know what if any functionality we get/use from JAX-RS that we might need to implement on our own. We would need a JSON parser.

Another option could be netty + json parser. As with undertow, there may be some functionality we currently get/use from JAX-RS that we might need to implement on our own. One potential advantage of netty over undertow is the support for additional protocols. The Cassandra driver is also built on netty.

The last option I have thought about is vert.x 3.0. It looks like the minimum/core runtime dependencies are netty, jackson, log4j, and slf4j. This is pretty slim as well. It gives us higher level APIs  and support for implementing REST endpoints. We also have support for additional protocols since this is built on netty.

Note that none of these options are based on any of JEE. One of my primary considerations for this has been minimal dependencies.


- John