Currently the console provides management operations for a very basic set of use cases. This needs to be extended for AS 7.1. Going forward we require your feedback. What do you think should be tackled next? Most of these questions are very problem domain specific. It would be great if all component leads could take some time and think about the following: - does my component expose reasonable management operations? - what would developers expect? what about system administrators? - how does play within a managed domain? - is my component part of a layered product? what's needed there? We don't expect you to provide the UI, but at least the low level management operations need to be implemented by your team. Think about the most frequently used operations. We don't need to expose every nitty gritty details of you configuration schema. It would be really great help, if you could assign somebody to be our point of contact for all questions management related. Make sure you plan some time early in this iteration so we can work through these issues. Prepare for change requests and new component releases. Last but not least, some areas that I believe can be improved: - security - clustering - ejb, jpa, weld

- transactions - messaging (non JMS) - infinispan Thanks for your help, Ike _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Heiko, Some of the JPA persistence providers support JMX for administrative operations (Hibernate statistics for example). Do we have any magic way to get JMX MBeans into the management console? Probably will need to be dynamic based on deployment time processing. Thanks, Scott

Quoting Scott Marlow <smarlow(a)redhat.com&gt;: > Heiko, > > Some of the JPA persistence providers support JMX for administrative > operations (Hibernate statistics for example).  Do we have any magic way > to get JMX MBeans into the management console?  Probably will need to be > dynamic based on deployment time processing. > > Thanks, > Scott Scott, Heiko is out for the rest of this month, so I'm not sure if he will be able to answer. Off hand, I don't think we currently have an easy way to directly access JMX from the console.  There would be a lot of low level transport stuff to deal with that we've already worked through for the management API.  I doubt that we would want to go and build a transport layer for JMX as well. I think the better question is can we (should we) expose JMX through the management API?  If so it would be accessible from both the console and the CLI. Does anyone have thoughts about this? Stan _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

What Brian is saying is that we will not map arbitrary JMX objects to the management mode. I think it might make sense though - eventually - to have a JMX resource which has operations for calling into JMX (for open mbean types only of course).  Note that this would NOT be a mapping, just a single management resource which is a gateway to JMX, and apart from accessing attributes and invoking operations, no other JMX functions would be supported (in particular, notifications). On 08/19/2011 11:29 AM, Eduardo Martins wrote: > It was and still is my biggest complain with AS7, the support for the > official java management spec is ... zero! > > IMHO the CLI should have an easy way to invoke a JMX operation, > whatever the MBean, how hard can it be when previous AS releases had > twiddle? And the JMX subsystem should have a module in the management > console, providing access to the MBeans in the JVM MBean server, > relying on JConsole is not good nowadays, not all OSes have it, again > we already had such tool... > > -- Eduardo > .............................................. > http://emmartins.blogspot.com > http://redhat.com/solutions/telco > > > > On Fri, Aug 19, 2011 at 4:35 PM,&lt;ssilvert(a)redhat.com&gt;  wrote: >> Quoting Scott Marlow&lt;smarlow(a)redhat.com&gt;: >>> Heiko, >>> >>> Some of the JPA persistence providers support JMX for administrative >>> operations (Hibernate statistics for example).  Do we have any magic way >>> to get JMX MBeans into the management console?  Probably will need to be >>> dynamic based on deployment time processing. >>> >>> Thanks, >>> Scott >> >> Scott, >> >> Heiko is out for the rest of this month, so I'm not sure if he will be >> able to answer. >> >> Off hand, I don't think we currently have an easy way to directly >> access JMX from the console.  There would be a lot of low level >> transport stuff to deal with that we've already worked through for the >> management API.  I doubt that we would want to go and build a >> transport layer for JMX as well. >> >> I think the better question is can we (should we) expose JMX through >> the management API?  If so it would be accessible from both the >> console and the CLI. >> >> Does anyone have thoughts about this? >> >> Stan >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Friday, August 19, 2011 11:52:40 AM Subject: Re: [jboss-as7-dev] JMX [was: Dear subsystem owners/components leads ....]

What kind of extensibility are you thinking about?

I have no objection at all to the kind of simple JMX gateway resource David describes. If someone in the community wants to contribute that, that would be great.

I would object to it though if its presence became an excuse for subsystems not exposing their full management API via the standard management model. ;)

On 8/19/11 12:02 PM, Eduardo Martins wrote: > The JMX exposure in CLI and Web Console can be basic, like I > mentioned, but should be easy extendable, so the community may > enhance > it, if there is interest... > > -- Eduardo > .............................................. > http://emmartins.blogspot.com > http://redhat.com/solutions/telco > > On Fri, Aug 19, 2011 at 5:52 PM, David M. > Lloyd&lt;david.lloyd(a)redhat.com&gt; wrote: >> What Brian is saying is that we will not map arbitrary JMX objects >> to >> the management mode. >> >> I think it might make sense though - eventually - to have a JMX >> resource >> which has operations for calling into JMX (for open mbean types >> only of >> course). Note that this would NOT be a mapping, just a single >> management resource which is a gateway to JMX, and apart from >> accessing >> attributes and invoking operations, no other JMX functions would >> be >> supported (in particular, notifications). >> >> On 08/19/2011 11:29 AM, Eduardo Martins wrote: >>> It was and still is my biggest complain with AS7, the support for >>> the >>> official java management spec is ... zero! >>> >>> IMHO the CLI should have an easy way to invoke a JMX operation, >>> whatever the MBean, how hard can it be when previous AS releases >>> had >>> twiddle? And the JMX subsystem should have a module in the >>> management >>> console, providing access to the MBeans in the JVM MBean server, >>> relying on JConsole is not good nowadays, not all OSes have it, >>> again >>> we already had such tool... >>> >>> -- Eduardo >>> .............................................. >>> http://emmartins.blogspot.com >>> http://redhat.com/solutions/telco >>> >>> >>> >>> On Fri, Aug 19, 2011 at 4:35 PM,&lt;ssilvert(a)redhat.com&gt; wrote: >>>> Quoting Scott Marlow&lt;smarlow(a)redhat.com&gt;: >>>>> Heiko, >>>>> >>>>> Some of the JPA persistence providers support JMX for >>>>> administrative >>>>> operations (Hibernate statistics for example). Do we have any >>>>> magic way >>>>> to get JMX MBeans into the management console? Probably will >>>>> need to be >>>>> dynamic based on deployment time processing. >>>>> >>>>> Thanks, >>>>> Scott >>>> >>>> Scott, >>>> >>>> Heiko is out for the rest of this month, so I'm not sure if he >>>> will be >>>> able to answer. >>>> >>>> Off hand, I don't think we currently have an easy way to >>>> directly >>>> access JMX from the console. There would be a lot of low level >>>> transport stuff to deal with that we've already worked through >>>> for the >>>> management API. I doubt that we would want to go and build a >>>> transport layer for JMX as well. >>>> >>>> I think the better question is can we (should we) expose JMX >>>> through >>>> the management API? If so it would be accessible from both the >>>> console and the CLI. >>>> >>>> Does anyone have thoughts about this? >>>> >>>> Stan >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Andy, that's our point of view, what about user/customers and integrators point of view? This is a new management API, yet management interfaces are not new, 3rd parties used something else before, very high chances it is JMX, do you really want to enforce the new management API as a condition to use AS7? -- Eduardo .............................................. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Aug 19, 2011 at 7:14 PM, Andrig Miller&lt;anmiller(a)redhat.com&gt; wrote: > > > ________________________________ > > From: "Brian Stansberry&quot;&lt;brian.stansberry(a)redhat.com&gt; > To: jboss-as7-dev(a)lists.jboss.org > Sent: Friday, August 19, 2011 11:52:40 AM > Subject: Re: [jboss-as7-dev] JMX [was: Dear subsystem owners/components > leads ....] > > What kind of extensibility are you thinking about? > > I have no objection at all to the kind of simple JMX gateway resource > David describes. If someone in the community wants to contribute that, > that would be great. > > I would object to it though if its presence became an excuse for > subsystems not exposing their full management API via the standard > management model. ;) > > That's exactly the slippery slope I don't want us to go down! From an > Andiamo perspective, we need ONE management layer that handles everything. > > Let's keep this on track. > > Andy > > On 8/19/11 12:02 PM, Eduardo Martins wrote: >> The JMX exposure in CLI and Web Console can be basic, like I >> mentioned, but should be easy extendable, so the community may enhance >> it, if there is interest... >> >> -- Eduardo >> .............................................. >> http://emmartins.blogspot.com >> http://redhat.com/solutions/telco >> >> On Fri, Aug 19, 2011 at 5:52 PM, David M. Lloyd&lt;david.lloyd(a)redhat.com&gt; >> wrote: >>> What Brian is saying is that we will not map arbitrary JMX objects to >>> the management mode. >>> >>> I think it might make sense though - eventually - to have a JMX resource >>> which has operations for calling into JMX (for open mbean types only of >>> course). Note that this would NOT be a mapping, just a single >>> management resource which is a gateway to JMX, and apart from accessing >>> attributes and invoking operations, no other JMX functions would be >>> supported (in particular, notifications). >>> >>> On 08/19/2011 11:29 AM, Eduardo Martins wrote: >>>> It was and still is my biggest complain with AS7, the support for the >>>> official java management spec is ... zero! >>>> >>>> IMHO the CLI should have an easy way to invoke a JMX operation, >>>> whatever the MBean, how hard can it be when previous AS releases had >>>> twiddle? And the JMX subsystem should have a module in the management >>>> console, providing access to the MBeans in the JVM MBean server, >>>> relying on JConsole is not good nowadays, not all OSes have it, again >>>> we already had such tool... >>>> >>>> -- Eduardo >>>> .............................................. >>>> http://emmartins.blogspot.com >>>> http://redhat.com/solutions/telco >>>> >>>> >>>> >>>> On Fri, Aug 19, 2011 at 4:35 PM,&lt;ssilvert(a)redhat.com&gt; wrote: >>>>> Quoting Scott Marlow&lt;smarlow(a)redhat.com&gt;: >>>>>> Heiko, >>>>>> >>>>>> Some of the JPA persistence providers support JMX for administrative >>>>>> operations (Hibernate statistics for example). Do we have any magic >>>>>> way >>>>>> to get JMX MBeans into the management console? Probably will need to >>>>>> be >>>>>> dynamic based on deployment time processing. >>>>>> >>>>>> Thanks, >>>>>> Scott >>>>> >>>>> Scott, >>>>> >>>>> Heiko is out for the rest of this month, so I'm not sure if he will be >>>>> able to answer. >>>>> >>>>> Off hand, I don't think we currently have an easy way to directly >>>>> access JMX from the console. There would be a lot of low level >>>>> transport stuff to deal with that we've already worked through for the >>>>> management API. I doubt that we would want to go and build a >>>>> transport layer for JMX as well. >>>>> >>>>> I think the better question is can we (should we) expose JMX through >>>>> the management API? If so it would be accessible from both the >>>>> console and the CLI. >>>>> >>>>> Does anyone have thoughts about this? >>>>> >>>>> Stan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

What kind of extensibility are you thinking about? I have no objection at all to the kind of simple JMX gateway resource David describes. If someone in the community wants to contribute that, that would be great. I would object to it though if its presence became an excuse for subsystems not exposing their full management API via the standard management model. ;) On 8/19/11 12:02 PM, Eduardo Martins wrote: > The JMX exposure in CLI and Web Console can be basic, like I > mentioned, but should be easy extendable, so the community may enhance > it, if there is interest... > > -- Eduardo > .............................................. > http://emmartins.blogspot.com > http://redhat.com/solutions/telco > > On Fri, Aug 19, 2011 at 5:52 PM, David M. Lloyd&lt;david.lloyd(a)redhat.com&gt;  wrote: >> What Brian is saying is that we will not map arbitrary JMX objects to >> the management mode. >> >> I think it might make sense though - eventually - to have a JMX resource >> which has operations for calling into JMX (for open mbean types only of >> course).  Note that this would NOT be a mapping, just a single >> management resource which is a gateway to JMX, and apart from accessing >> attributes and invoking operations, no other JMX functions would be >> supported (in particular, notifications). >> >> On 08/19/2011 11:29 AM, Eduardo Martins wrote: >>> It was and still is my biggest complain with AS7, the support for the >>> official java management spec is ... zero! >>> >>> IMHO the CLI should have an easy way to invoke a JMX operation, >>> whatever the MBean, how hard can it be when previous AS releases had >>> twiddle? And the JMX subsystem should have a module in the management >>> console, providing access to the MBeans in the JVM MBean server, >>> relying on JConsole is not good nowadays, not all OSes have it, again >>> we already had such tool... >>> >>> -- Eduardo >>> .............................................. >>> http://emmartins.blogspot.com >>> http://redhat.com/solutions/telco >>> >>> >>> >>> On Fri, Aug 19, 2011 at 4:35 PM,&lt;ssilvert(a)redhat.com&gt;    wrote: >>>> Quoting Scott Marlow&lt;smarlow(a)redhat.com&gt;: >>>>> Heiko, >>>>> >>>>> Some of the JPA persistence providers support JMX for administrative >>>>> operations (Hibernate statistics for example).  Do we have any magic way >>>>> to get JMX MBeans into the management console?  Probably will need to be >>>>> dynamic based on deployment time processing. >>>>> >>>>> Thanks, >>>>> Scott >>>> >>>> Scott, >>>> >>>> Heiko is out for the rest of this month, so I'm not sure if he will be >>>> able to answer. >>>> >>>> Off hand, I don't think we currently have an easy way to directly >>>> access JMX from the console.  There would be a lot of low level >>>> transport stuff to deal with that we've already worked through for the >>>> management API.  I doubt that we would want to go and build a >>>> transport layer for JMX as well. >>>> >>>> I think the better question is can we (should we) expose JMX through >>>> the management API?  If so it would be accessible from both the >>>> console and the CLI. >>>> >>>> Does anyone have thoughts about this? >>>> >>>> Stan >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Heiko, Some of the JPA persistence providers support JMX for administrative operations (Hibernate statistics for example). Do we have any magic way to get JMX MBeans into the management console? Probably will need to be dynamic based on deployment time processing.

How can an user deploy a custom build component that exposes user defined management operations? For example a custom SLSB pool implementation.