WildFly stack

[john.sanda]

I have some questions about what the WildFly stack is/will look like. I downloaded wildfly-core-8.0.0.Final. The rest-servlet war did not deploy. It did deploy on a full installation of wildfly-8.0.0.Final. What needs to be done to get it to deploy on WildFly Core?

I noticed that we are using EJB in the rest-servlet module. I assume using EJB will require additional dependencies, which brings me to my second question. Do we really need EJB? We obviously do not need transactions.

In order to support aggregate metrics, we will need something for scheduled tasks to execute the aggregation job. What are our options in WildFly? I briefly looked at the Quartz docs to see if it can be used without a database, and there is a RAMStore. I do not think schedules and jobs are persisted across restarts, but we RAMStore might be doable.

We have talked about running on WildFly core, but we already need to add

• The undertow subsystem for WARs
• JAX-RS
• something for scheduled task execution
• EJB?

Does it make more sense to start with the full WildFly distribution and take out what we do not need?

[mithomps]

We seem to already be contradicting some of the high level requirements asked by other teams and agreed upon by us.

See comments regarding embed-ability, minimal dependencies and no EE dependencies : https://community.jboss.org/wiki/HighLevelRequirements#comment-13562

From our discussions Fuse has similar requirements keeping it minimal.

These imply a container-less option for product embedding.

Are these still the correct high level requirements or do they need adjusting?

[heiko.braun]

I think we should be able to run on wf core with just undertow. Both ejb and jax-rs should not be needed. Ejb is certainly overkill and jax-rs can be dropped if we use the native undertow http api for exposing rest endpoints.

[theute]

No EJB. (JAX-RS if we need)

[pilhuhn]

I do not tink that, at least for the start, it makes a lot of sense to re-implement all the http request parsing, marshalling and unmarshalling that JAX-RS has built-in.

[heiko.braun]

I think the rest api itself gets too much attention in this discussion. It's probably going to be the least complex component of the metric system, don't you think?

IMO to pull on something like RESTeasy and all it's dependencies requires a good justification. Convinience doesn't matter in this case, because I don't expect the REST API to be constantly changing.

Am 20.05.2014 um 12:06 schrieb Heiko Rupp <[e-mail]>:

JBoss Community

WildFly stack

reply from Heiko Rupp in rhq-metrics - View the full discussion

I do not tink that, at least for the start, it makes a lot of sense to re-implement all the http request parsing, marshalling and unmarshalling that JAX-RS has built-in.

Reply to this message by going to Community

Start a new discussion in rhq-metrics at Community

Following rhq-metrics in these streams: Email Watches

Following WildFly stack in these streams: Inbox

[mithomps]

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.

[nstefan]

Heiko Braun wrote:

I think the rest api itself gets too much attention in this discussion. It's probably going to be the least complex component of the metric system, don't you think?

IMO to pull on something like RESTeasy and all it's dependencies requires a good justification. Convinience doesn't matter in this case, because I don't expect the REST API to be constantly changing.

I am confused about the REST discussion because the UI is a big component of the project charter. There is no way to deliver charts or any UI unless there is an HTTP based interface to move data back and forth. I am going to use REST as an example but it can be websockets or SOAP or anything that moves data over HTTP.

Now the argument goes a few ways over the role of REST:

1) No REST interface -> No UI. Data would be pumped into RHQ Metrics but consumers have to build their own client to use the data. The charts that we've been developing are very complex. Replicating that functionality is neither trivial nor should be the focus of the consumers. And if we take away the charts from the project charter then we might as well have no UI component in the project. And why should we take away the UI component if it is not trivial. Circular argument ...

2) REST interface is secondary -> REST does not get a lot of attention. This is counter productive because the main method of getting anything useful out of this endeavor becomes a second concern. Unless there is a simple, good, efficient way for users to visualize or act on the data, might as well not collect it at all. I would not minimize this aspect because then the whole purpose of RHQ Metrics goes away.

3) REST interface is primary - REST gets the most attention and is a requirement for deployment. Then there are no issues with having good visual or programmatic interfaces readily available for consumers. In the context of Wildfly, we could provide a java interface for pumping metrics just to make things a little more efficient. But the REST interface is required to be installed and active at all times.

To me the third option is the only one that fits the project charter. The goal is to take all the complexity away from anybody that needs to collect and use metrics. Consumers should only be concerned with two things: pump data in and use data stored; put & get or put & see. Everything else should be left to the RHQ Metrics project. Moreover, JSON over REST is the linguaga franka of internet services. Using it gives any consumers the flexibility to build additional services on top of the RHQ Metrics with little effort.

[heiko.braun]

Thats not what I mean. Of course it requires a REST interface, especially for the  GUI. With regard to this I fully agree with you. But i was talking about the means to implement the REST API. Something like JAX-RS would be convinient, but bloated. I think we can strip a lot of dependencies when we chose a more low level approach for implementing the REST API.

[theute]

Going with Jax-RS/RESTEasy is a pragmatic solution to get something solid and early.

Yes we can do differently, and yes there is always a lower/faster layer, but we need it relatively soon and once the API is stable we may have time, in parallel to try other ways and compare performance, footprint...

There is noone really fulltime on this, let's get this rolling.

[john.sanda]

I am confused. We had a full, end to end working prototype built with Vert.x with minimal dependencies beyond Vert.x itself, and it was very easily embeddable. For reasons I still do not understand we decided against that and now are moving forward with an implementation that requires a full WildFly container or certainly more than WildFly Core. [Deprecated] High Level Requirements cites

• The project should be easy to consume as a library and as a stand alone server
• Dependencies should be minimal
• It should be usable in a non-JEE environment

Are these requirements still important? I feel like the immediate, short term goals are becoming more unclear.

[theute]

I may miss the "easily embeddable" aspect of vert.x but for the rest:

• The project should be easy to consume as a library and as a stand alone server

What I meant is that there are several options to use RHQ Metrics:

• a client can query a JAVA API (library) and run the metrics as part of the same process. (Ex: Fabric8 storing metrics and retrieving metrics through a JavaAPI, technically he adds a few jar dependencies in his pom.xml).
• a client can query a remote API where an RHQ Metrics server runs (clients needs to know the full URL of the server)
• a servlet-based client can embed a WAR with the same functionality (+ WAR for the UI)

• Dependencies should be minimal

We have to weigh pros and cons to add a dependency. I do think that embedding RESTEasy will help us speed up things and that's a dependency we can remove later if needed without changing the overall infrastructure.

• It should be usable in a non-JEE environment

I really meant non-full-EE environment. WF-Core + Web is ok and again we may have the option to remove Web dependency later (or we can add parts later).

I should have added: Manageable.

As of now the vert.x solution requires to pass ports in property file or system property IIRC, this is a small layer of basic management already involved. WF-Core gives that to us. For me this is the major let down to use vert.x as a platform.

My order of preference:

1. WF-Core + RESTEasy -> Fast to implement, robust, give us a good base, light enough
2. WF-Core with native undertow -> This would be my preferred option but I am hesitant on the fact that it will require more work (and more subject to bugs as it requires more "manual" work) and I am more ignorant on this one. In a WF environment, this would allow us to have RHQ metrics embedded as WF modules IIRC (a win), not sure how that works outside of WF though (Plain tomcat ?)
3. vert.x -> No management
4. Karaf

[tsegismont]

John Sanda a écrit:

I am confused. We had a full, end to end working prototype built with Vert.x with minimal dependencies beyond Vert.x itself, and it was very easily embeddable. For reasons I still do not understand we decided against that and now are moving forward with an implementation that requires a full WildFly container or certainly more than WildFly Core.

Are these requirements still important? I feel like the immediate, short term goals are becoming more unclear.

+1. I have not much participated in this thread but from a reader perspective it's not really easy to understand.

[tsegismont]

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

[bdaw]

For LiveOak easiest initial integration at this point would be to just drop a war with metrics. Thats how we'll embed AeroGear UPS.

Minimal dependencies requirement still apply - it is handy if you want to keep the stack minimum and close to pure WF Core. Thats what where we aim in the future.

We made a similar journey with LiveOak. Started as a Netty based server with bits of Vert.x and leveraging jboss modules. We ended up on top of WildFly full right now. Part of the reason was using KeyCloak, UPS and few other things. We still aim to cleanup more dependencies down the road and be closer to WF Core. However going with WF gave us few benefits and simply allowed to deliver faster.

Regarding Vert.x my major concern would be embedding/bundling it in a project built on top of WF.

Second biggest concern is around your target requirements. While it is technically appealing to start clean and small with vert.x the biggest question is how much of WildFly you will need to reimplement yourself down the road. If management layer is your requirement like Thomas mentioned there is a certain risk there. With WF Core you also get MSC and jboss modules wich is a huge benefit. 

I think you should just aim to have clean SPI to make it easy to bootstrap in different environment if desired. Still for practical reasons I would aim WF atm.