JBossDeveloper

Thomas Segismont wrote:

 

Thomas Heute a écrit:

 

I may miss the "easily embeddable" aspect of vert.x

 

To be honest I may also miss the "easily embeddable" aspect of WF Core

As a library WF-Core or vert.x doesn't make a difference as it shouldn't be involved.

A WAR is easy to consume if you have an app running on a servlet container. Think Fabric8 or LiveOak or Aerogear usecases. (WF modules is even better to consume (debatable) but requires the client to be on WF)

If you are on vert.x, for instance, you can use the library but you can't host the REST endpoints for the UI aspect (unless we provide this at some point as an alternative).

So yes, the notion of embebdable varies depending on environment you consider, but our most immediate consumers are: Fabric8, WildFly, LO, Aerogear, RHQ none are vert.x based (LO actually changed from vert.x to Netty to WF-Core)

I would agree with Heiko that REST could actually be an add-on module (probably a very popular one). We could get data in/out of Undertow via websockets (even to a UI or CL/IJ) for very lean core product with hardly any dependencies (especially if base is in-memory db). The REST module add-on would also be nice with respect to security and embed-ability.

I don't mind how we implement this, but for me it is very important that a user is able to

curl http://localhost:8080/rhq-metrics/snert.cpu_system/data

and

curl -X POST http://localhost:8080/rhq-metrics -d@/tmp/fooX -HContent-Type:application/json

to read and deliver data. The simple reason is that you get a http-stack on almost all devices out there (e.g. Arduinos, zOS, ...) and almost every programming language has methods to easily deal with http. Not offering this will dramatically limit the usefulness.

We can offer websockets in addition for optimized communication as well as a myriad of other protocols ( jdbc anyone? :-)

Here's my take.

I don't really care about the underlying container chosen for the "standalone" mode of the metrics server. As long as the server is light enough to run "in the cloud" then we're good (both Vert.x and WF core fulfill this requirement). I think the primary goal should be to get a version 1 of the metrics server out as soon as possible. And if we find that Container X is a not good choice then let's have this discussion again before version 2. At that time, it will make much more sense.

I think this thread has grown much because we have not clearly defined what we expect with "embeddability". If Fabric8 wants to "embed" rhq-metrics features, will a WAR file or Verticles be a solution? I'm not sure. To my mind, embeddability sounds like something which does not depend on any container.

I said (maybe in another thread) that I wanted 2 WARs, one for the REST endpoint, one for the UI.

Le 21/05/2014 10:50, Thomas Heute a écrit :

As a library WF-Core or vert.x doesn't make a difference as it shouldn't

be involved.

 

Agreed, that's how I understand "pure" embeddability. No dependency on

any container/programming model. I'm not sure that's what all parties

want for version 1

A WAR is easy to consume if you have an app running on a servlet

container. Think Fabric8 or LiveOak or Aerogear usecases. (WF modules is

even better to consume (debatable) but requires the client to be on WF)

 

If you are on vert.x, for instance, you can use the library but you

can't host the REST endpoints for the UI aspect (unless we provide this

at some point as an alternative).

 

So yes, the notion of embebdable varies depending on environment you

consider, but our most immediate consumers are: Fabric8, WildFly, LO,

Aerogear, RHQ none are vert.x based (LO actually changed from vert.x to

Netty to WF-Core)

 

If all our "immediate" consumers don't care about pure embeddability

and want a Java EE7 WAR file then yes, let's stop the conversation, pick

Wildfly and get a version 1 out ASAP which will meet our "standalone"

and their "embeddable" requirements.

Thomas Heute schrieb:

 

I said (maybe in another thread) that I wanted 2 WARs, one for the REST endpoint, one for the UI.

+1 (actually this is what we have in git right now with rest-servlet and dummy-ui (which is only a placeholder).

Btw. rest-servlet has now the wiring to use C* as default.

the easiest way to deploy a UI is a WAR; not all customers have public internet access; so being able to deploy a UI (even if its static HTML/CSS/JS) is useful. e.g. hawtio is available as a WAR.

Though the WAR could be the REST API and the UI stuff too (so the UI stuff could easily be packaged in the WAR for the REST API)

Regarding no dependency on any programming model or container:

Thats what I said in the beginning. And I think this still holds for the core components and services. But there also seems to be agreement that we want one executable package out-of-the-box that resembles the core services.

It seems that we decided for WF.Core, plus anything we need in addition to that?

Not only do all user have unlimited internet access, a UI usually consists of more than one html page, but of many more resources like JS-libraries, css files and images. Of course they could even be served by the jvms http server. Having them bundled together in some form of archive (and a .war is effectively a .zip in disguise) can be pretty helpful.

So, talking to John some more (and James)...

Short version: We go with WF-Core + Jax-RS as "reference implementation" if someone has nights and weekends and want to compare to the RI then good

I have changed the High level requirements (which was just a dirty draft) [Deprecated] High Level Requirements

This includes the requirements for a web archive as a way to integrate RHQ Metrics. We will also provide a standalone server (Initially WF with the webarchive(s))

That said, for sure "core components and services" should not be bound to any server/container obviously and this is already the case for https://github.com/rhq-project/rhq-metrics/tree/master/metrics-core

I also understand that to be used by Wildfly for the console it will require another flavor, which would likely rely on undertow and shipped as a Wildfly module (or subsystem). Would be great if the EAP team contributes this.

*Later* we would like to extract alerts from RHQ (actually have a more advanced version) and this may be a separate project, at this point we may even extract the servers to its own project to combine Metrics+alerts, at that point RHQ Metrics would not care less about WF or vert.x or Karaf...

Now I hope we can move on I would like to agree/nail down (in separate threads/documents)

• Metrics Java API rhq-metrics/metrics-core/src/main/java/org/rhq/metrics/RHQMetrics.java at master · rhq-project/rhq-metrics · GitHub
• Metrics REST API
• Angular Directives definitions (mike ? any suggestion (in another thread ))
• Start discussing Alerts and how it can be separated from RHQ, it's likely optionally dependent on Metrics (to alert if current load < 0.5*load of last week)

And obviously clean up the repo, provide in-memory implementation (without Cassandra dependency), perf tests...