I've just sent another email on rhq-devel with a list of the components
of rhq-metrics and the form in which they come. Read it and you should
no longer worry too much about our adherence to EE7.
The focus over the last two months has been to get something with the
base capabilities up and running. So Wildfly server, CDI and JAX-RS
helped us in this regard. But nothing is set in stone.
May I ask what your plans are for the Wildfly Console? Which features
are you expecting from rhq-metrics?
I think we need to answer these questions before deciding anything.
Thanks,
Thomas
Le 09/01/2015 09:31, Heiko Braun a écrit :
> On 08 Jan 2015, at 19:17, John Sanda <jsanda(a)redhat.com
> <mailto:jsanda@redhat.com>> wrote:
>
> What do you think about deploying rhq-metrics as a WF extension?
This is my ultimate goal and the reason for many of my questions. In
order to leverage rhq-metrics in wildfly, it’s needs to be properly
integrated and have a reasonable out-of-the-box experience.
Some of my contributions (wildfly-monitor, cassandra-subsystem) have
been intended to provide the pre-requisites to further integrate
rhq-metrics.
However we face some challenges to fully integrate rhq-metrics as a
wildfly extension, including the corresponding subsystems:
a) Support for domain mode
To support the wildfly domain mode, we need to know how the metrics
components are intended to be used in multi node environment (aka
several vm’s operating as a whole)
It’s unclear to what degree the data partitioning and retention rules
apply to such an environment. The question is true for other jobs that
require some level of coordination (i.e. processing rollups).
IMO this is the biggest gap at the moment: these requirements are
unclear/undefined and all examples currently assume a single, standalone
wildfly instance.
b) API and service dependencies
Integration on the level of a wildfly extension comes with a lot of
constraints. Most notable the availability of certain API’s and service
at this level. Most of rhq-metrics components assume the availability of
a full EE7 stack and it’s API’s. We can certainly discuss an extension
of the low level API’s that wildfly provides to certain degree, but it
will never provide the full EE7 API for extensions.
At the moment this is a real blocker to further integrate rhq-metrics.
There are ways to circumvent these problems, but only by providing
dedicated implementations of some rhq-metrics-core API’s. This
effectively prevents re-use and would put us in a position of having to
catch up with the latest functional enhancements.
Regards, HeikoB
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel