1:35 a.m.
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.
Thoughts?
4:03 a.m.
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 ?
Thomas
Thoughts?
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:17 p.m.
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
6:52 p.m.
Am 21.01.2015 um 05:17 schrieb John Sanda <jsanda(a)redhat.com>:
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.
WildFly has afaik Jackson as mapper in its list of modules.
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.
So we pull in (yet another version of) netty into WIldFly to workaround its existing
Undertow http thingy?
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.
10:33 p.m.
On Jan 21, 2015, at 4:52 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
> Am 21.01.2015 um 05:17 schrieb John Sanda <jsanda(a)redhat.com>:
>
> 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.
WildFly has afaik Jackson as mapper in its list of modules.
I do not see it in WF Core 8.2.0.Final. I have not checked more recent versions WF Core
though.
>
> 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.
So we pull in (yet another version of) netty into WIldFly to workaround its existing
Undertow http thingy?
The issue here is not trying to work around undertow. The issue is that hawkular-metrics
currently requires more than WF Core to be embedded in WF. If I understand correctly, it
would be find if our solution requires dependencies X, Z provided they remain
implementation details and can be packaged up as a module because then it WF Core would
just require that additional module instead as opposed to more WF services. With that
said, it will be easier to embed in general with fewer dependencies.
With respect to netty, we already require it for the Cassandra driver. I think it would
make sense for metrics and the driver to use the same version. Then we are not pulling in
yet another version.
> 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.
11:35 p.m.
On 21.01.2015 15:33, John Sanda wrote:
I do not see it in WF Core 8.2.0.Final. I have not checked more
recent
versions WF Core though.
There's no JSON parser in the wildfly-core as far as I can see.
wildfly/pom.xml includes jackson2. It is however used in some of the
examples done by the Undertow group (such as the performance race, where
there is a JSONHandler). Hardly a complex task.
- Micke
1:36 a.m.
On Jan 21, 2015, at 9:35 AM, Michael Burman
<miburman(a)redhat.com> wrote:
On 21.01.2015 15:33, John Sanda wrote:
> I do not see it in WF Core 8.2.0.Final. I have not checked more recent
> versions WF Core though.
There's no JSON parser in the wildfly-core as far as I can see.
wildfly/pom.xml includes jackson2. It is however used in some of the
examples done by the Undertow group (such as the performance race, where
there is a JSONHandler). Hardly a complex task.
I don’t think particular json parser is too important for the discussion. The issue is
embedding in WF currently requires deploying additional WF services above and beyond what
is in WF core. Whether we use jackson, gson, or something else will not require additional
WF services. The parser will be a self-contained dependency.
3:47 a.m.
On 21 Jan 2015, at 14:33, John Sanda <jsanda(a)redhat.com
<mailto:jsanda@redhat.com>> wrote:
The issue here is not trying to work around undertow. The issue is that hawkular-metrics
currently requires more than WF Core to be embedded in WF. If I understand correctly, it
would be find if our solution requires dependencies X, Z provided they remain
implementation details and can be packaged up as a module because then it WF Core would
just require that additional module instead as opposed to more WF services. With that
said, it will be easier to embed in general with fewer dependencies.
yes, both undertow and netty fall into this category. undertow has the benfit of being
present in WF already. Netty on the other hand was brought to the table, because it has
more out-of-the-box protocols. Not sure if that’s needed though.
5:04 a.m.
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
[1] http://undertow.io/documentation/core/undertow-handler-guide.html
<http://undertow.io/documentation/core/undertow-handler-guide.html>
[2] http://undertow.io/documentation/core/bootstrapping.html
5:48 a.m.
On Jan 21, 2015, at 3:04 PM, Heiko Braun <hbraun(a)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
[1] http://undertow.io/documentation/core/undertow-handler-guide.html
<http://undertow.io/documentation/core/undertow-handler-guide.html>
[2] http://undertow.io/documentation/core/bootstrapping.html
<http://undertow.io/documentation/core/bootstrapping.html>
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
11:28 a.m.
On Jan 22, 2015, at 3:48 PM, John Sanda <jsanda(a)redhat.com>
wrote:
On Jan 21, 2015, at 3:04 PM, Heiko Braun <hbraun(a)redhat.com
<mailto: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
>
> [1] http://undertow.io/documentation/core/undertow-handler-guide.html
<http://undertow.io/documentation/core/undertow-handler-guide.html>
> [2] http://undertow.io/documentation/core/bootstrapping.html
<http://undertow.io/documentation/core/bootstrapping.html>
>
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
The more I think about this the more I think that the hawkular team should own this. One
of the initial requirements for metrics early on was minimal dependencies in order to make
it easy to embed. Stefan said he would start looking into an implementation built on
undertow core. As far as the questions around maintaining the current JAX-RS
implementation versus (or in addition to) something else, I do not think we need to rush a
decision. I think we ought to at least get a working prototype in place and then revisit
that discussion.
3389
days inactive
3395
days old
11 comments
6 participants
participants (6)
-
Heiko Braun -
Heiko W.Rupp -
John Mazzitelli -
John Sanda -
Michael Burman -
Thomas Heute