[wildfly-dev] Is JMX Needed in Core?

[Patton, John]

I'll check if we did.  We're looking into releasing the code we built to
expose the metrics, but we have to get approvals and it's taking a while.

Perhaps my thoughts are out of scope for the one conversation I decided to
jump into. :)  But, I do like having JMX available in the full dist and
enabling the modules in the provisioning tool.  That sounds appealing
irrespective of the trouble we had grabbing various metrics once we got
JMX working.  JMX has felt a bit like an afterthought with wildfly.

Cheers,

-john




On 7/9/14 2:12 PM, "Brian Stansberry" <brian.stansberry at redhat.com> wrote:

>If things you need are not exposed via the undertow subsystem management
>API, please file feature request JIRAs. Or even better, send a patch if
>you exposed it via the subsystem.
>
>On 7/9/14, 1:55 PM, Patton, John wrote:
>> I'd like to vote for adding it into the full dist and configuring the
>> provisioning tool to grab the JMX modules.
>>
>> We rely on JMX for accessing specific monitoring metrics and it's
>> difficult to get at some of the metrics that used to be easily available
>> in prior versions for some metrics.  We've had to jump through some
>>hoops
>> to get JMX working the way we need in wildfly 8 -- with the new undertow
>> module, we had to write some code to expose some metrics that used to be
>> part of the jbossweb module, like avgResponseTimeMS and requestCount.
>> Would be awesome if JMX support was more complete and part of the full
>> dist.
>>
>> Cheers,
>>
>> John H Patton
>>
>>
>>
>> On 7/9/14 1:27 PM, "Brian Stansberry" <brian.stansberry at redhat.com>
>>wrote:
>>
>>> My earlier reply on this thread was in the branch focused on the
>>> technical detail of how the dependency arises. Which should be fixed;
>>> sounds like that's happening.
>>>
>>> On the broader question of where stuff belongs, JMX is an interesting
>>> case. Lots of users will want JMX. A number of subsystems have optional
>>> dependencies on it, including some like jgroups and infinispan that may
>>> end up being part of their own dist, separate from the full dist.
>>>
>>> So what's the plan for catering to these needs? Ship it in the full
>>>dist
>>> and those who want it depend on the full dist but configure the
>>> provisioning tool to only grab the JMX modules? Make it a micro-dist?
>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as
>>> the "deploy your own services" dist? (I don't like that last one, just
>>> brainstorming...)
>>>
>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote:
>>>> Working with the split repo just questioning if JMX is really needed
>>>>in
>>>> core?
>>>>
>>>> Whilst most distributions would include it I am not convinced it is a
>>>> subsystem all must have.
>>>>
>>>
>>> Manageable logging isn't either. Lots of people used logging.properties
>>> for a long time.
>>>
>>> Note I'm not advocating removing logging from core; I'm just saying
>>>that
>>> no subsystem has to be in core if that's the criteria.
>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> This message, including any attachments, is the property of Sears
>>Holdings Corporation and/or one of its subsidiaries. It is confidential
>>and may contain proprietary or legally privileged information. If you
>>are not the intended recipient, please delete it without reading the
>>contents. Thank you.
>>
>
>
>-- 
>Brian Stansberry
>Senior Principal Software Engineer
>JBoss by Red Hat

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.