On Jan 20, 2015, at 2:03 PM, Thomas Heute <theute(a)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