Dear subsystem owners/components leads ....

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Dear subsystem owners/components leads ....

Heiko Braun


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

Scott Marlow
On 07/14/2011 06:25 AM, Heiko Braun wrote:

>
>
> 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

For jpa, I would like to do a lot but I'm not sure how much fits into
the 7.1 schedule.

- Should allow the default datasource to be configured.  If a
(persistence.xml) persistence unit definition doesn't specify the
datasource, the default datasource is used.  This isn't required by the
EE spec but makes it easier to migrate applications to/from JBoss (since
other EE app servers also support this).  This can be currently set in
standalone.xml (or other xxx.xml).  [SHOULD DO THIS ONE]

- Show persistence provider specific statistics (e.g. the Hibernate
statistics that might of been viewed before in the jmx console).  We are
restructuring the jpa classes that are specific to each persistence
provider, to allow for more than one set of integration classes.  We
will probably need the provider integration classes
(PersistenceProviderAdaptor implementations) to include metadata about
what the persistence provider supports for management.  Will also need
bridge code to bring the persistence providers statistics/operations
into the management console.  [NEED TO ASSESS PRIORITY VERSUS OTHER 7.1
TASKS]

- Show jpa subsystem/container statistics.  [NEED TO ASSESS PRIORITY
VERSUS OTHER 7.1 TASKS]

- Via trace logging, we currently show the elapsed time of each entity
manager operation.  I would like to do more but not sure if that will be
7.1 or later.  I'm thinking of some type of event log, that can be
scanned to show higher level operations (e.g. how long a db transaction
took and the individual jpa operation duration within the tx).  I would
want to see this be written to by multiple containers and could be read
by any tool.  +1 if there are hooks for plugging in the management
component that generates the event log.  [FUTURE OPEN ENDED IDEA]

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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

Scott Marlow
On 07/14/2011 08:59 AM, Scott Marlow wrote:

> On 07/14/2011 06:25 AM, Heiko Braun wrote:
>>
>>
>> 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
>
> For jpa, I would like to do a lot but I'm not sure how much fits into
> the 7.1 schedule.
>
> - Should allow the default datasource to be configured.  If a
> (persistence.xml) persistence unit definition doesn't specify the
> datasource, the default datasource is used.  This isn't required by the
> EE spec but makes it easier to migrate applications to/from JBoss (since
> other EE app servers also support this).  This can be currently set in
> standalone.xml (or other xxx.xml).  [SHOULD DO THIS ONE]
>
> - Show persistence provider specific statistics (e.g. the Hibernate
> statistics that might of been viewed before in the jmx console).  We are
> restructuring the jpa classes that are specific to each persistence
> provider, to allow for more than one set of integration classes.  We
> will probably need the provider integration classes
> (PersistenceProviderAdaptor implementations) to include metadata about
> what the persistence provider supports for management.  Will also need
> bridge code to bring the persistence providers statistics/operations
> into the management console.  [NEED TO ASSESS PRIORITY VERSUS OTHER 7.1
> TASKS]
>
> - Show jpa subsystem/container statistics.  [NEED TO ASSESS PRIORITY
> VERSUS OTHER 7.1 TASKS]

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

>
> - Via trace logging, we currently show the elapsed time of each entity
> manager operation.  I would like to do more but not sure if that will be
> 7.1 or later.  I'm thinking of some type of event log, that can be
> scanned to show higher level operations (e.g. how long a db transaction
> took and the individual jpa operation duration within the tx).  I would
> want to see this be written to by multiple containers and could be read
> by any tool.  +1 if there are hooks for plugging in the management
> component that generates the event log.  [FUTURE OPEN ENDED IDEA]
>
>> - transactions
>>
>> - messaging (non JMS)
>> - infinispan
>>
>>
>> Thanks for your help,
>>
>> Ike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

JMX [was: Dear subsystem owners/components leads ....]

Stan Silvert
Quoting Scott Marlow <[hidden email]>:
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Brian Stansberry
On 8/19/11 10:35 AM, [hidden email] wrote:

> Quoting Scott Marlow<[hidden email]>:
>> 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?
>

We could only expose stuff that has an open mbean interface.

I don't like the idea of generally exposing everything that's in JMX via
the management API, e.g. with some resource tree
/jmx-domain=somedomain/some-objectname-key=some-objectname-value. The
problem is for that stuff the management layer would really just be a
thin wrapper over whatever unknown stuff a tech exposes in JMX, and that
unknown stuff would very likely include persistent configuration stuff.
Any use of that part of the management API would bypass the true
management layer.

Wherever possible we should focus on adding a proper domain management
layer for any tech we integrate that exposes whatever runtime stuff we
want from that tech's management interface but properly uses the domain
model for any persistent config.

Kabir's working on exposing the domain management layer via JMX. Those
mbeans will be in their own JMX domain. We'll clearly document that for
those using JMX, that JMX domain is the only safe one to use for any
persistent configuration.




--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

Brian Stansberry
In reply to this post by Scott Marlow
On 8/19/11 9:58 AM, Scott Marlow wrote:

<snip/>

>
> 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.
>

 From our discussion today on #jboss-as7-dev


[10:44am] smarlow: bstansberry: does your work on AS7-340, help me to
show Hibernate statistics (assuming I get them registered with the
platform mbean server)?  I assume that is the idea but wanted to make sure
[10:44am] jbossbot: jira [AS7-340] Expose platform mxbeans via the
domain model [Coding In Progress (Unresolved) Feature Request, Major,
Brian Stansberry] https://issues.jboss.org/browse/AS7-340
[10:45am] bstansberry: smarlow: no, not at all
[10:45am] bstansberry: i'm exposing the mbeans discussed in the
java.lang.management package
[10:46am] bstansberry: a generic facility to expose any arbitrary mbean
is a whole different animal
[10:46am] bstansberry: is that really what you're doing though, or are
you exposing hibernate stuff with a known API?
[10:47am] smarlow: bstansberry:  I'm just talking at this point
[10:47am] bstansberry: IIRC, hibernate has a regular typed API for
everything they expose via JMX
[10:49am] bstansberry: it might be possible to have a generic mapping
layer that could represent any open mbean as a management model resource
[10:50am] barreiro joined the chat room.
[10:50am] smarlow: bstansberry:  I'm not sure of the priority of such
work, was just looking for something low cost that could fit in
[10:50am] bstansberry: but there would need to be some logic that
determines where in the tree things belong and properly wire it in
[10:51am] bstansberry: i don't think it would be very low cost
[10:51am] smarlow: bstansberry:  would be nice if any persistence
provider could have its management operations/properties show up
[10:51am] smarlow: bstansberry:  doesn't sound like it.
[10:55am] bstansberry: smarlow: is there any sort of standard contract
for how persistence providers expose management stuff?
[10:59am] smarlow: bstansberry:  not at all
[11:00am] bstansberry: ok, so there would need to be some sort of
contract that we provide, and a PU provider that wants to show up in our
management model would have to implement that contract and map it to
whatever the use internally
[11:01am] smarlow: bstansberry:  makes sense, probably would need to do
that in our integration classes for the pu provider
[11:01am] bstansberry: perhaps that implementation could be included
with the module that contains the PO provider. use something like a
ServiceLoader to discover it
[11:01am] bstansberry: smarlow: right
[11:02am] bstansberry: and whether that impl exists or not depends on
whether someone cares to provide it
[11:03am] smarlow: bstansberry:  we can add add that to our SPI for PU
provider integration classes
[11:06am] jpederse: smarlow: you already have the JCA SPI to look at for
ideas
[11:07am] smarlow: jpederse: good to have an example, was just trying to
understand what is already free
[11:08am]

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Eduardo Martins
In reply to this post by Stan Silvert
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,  <[hidden email]> wrote:

> Quoting Scott Marlow <[hidden email]>:
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

David Lloyd-2
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,<[hidden email]>  wrote:
>> Quoting Scott Marlow<[hidden email]>:
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Eduardo Martins
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 <[hidden email]> 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,<[hidden email]>  wrote:
>>> Quoting Scott Marlow<[hidden email]>:
>>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Brian Stansberry
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<[hidden email]>  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,<[hidden email]>    wrote:
>>>> Quoting Scott Marlow<[hidden email]>:
>>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Andrig Miller



From: "Brian Stansberry" <[hidden email]>
To: [hidden email]
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<[hidden email]>  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,<[hidden email]>    wrote:
>>>> Quoting Scott Marlow<[hidden email]>:
>>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Eduardo Martins
In reply to this post by Brian Stansberry
With easy extension I mean to be possible for people to add other not
so basic JMX features, to build on top of it, if they really need it.

Now with respect to this stuff becoming an excuse to not use the
management API... I think even 3rd party systems will use it, all
depends on what people get from it, but note they will be developing
on top of something proprietary, that is a "no way" for some 3rd
parties. But for a start, having basic JMX features in the management
tools is a must, very important for easier migrations, not only from
older JBoss AS versions, but also from competing products.

Expose the bait... get people in the shop, then sell what really
matters, otherwise you risk not sell anything at all.

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco



On Fri, Aug 19, 2011 at 6:52 PM, Brian Stansberry
<[hidden email]> wrote:

> 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<[hidden email]>  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,<[hidden email]>    wrote:
>>>>> Quoting Scott Marlow<[hidden email]>:
>>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Eduardo Martins
In reply to this post by Andrig Miller
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 <[hidden email]> wrote:

>
>
> ________________________________
>
> From: "Brian Stansberry" <[hidden email]>
> To: [hidden email]
> 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<[hidden email]>
>>  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,<[hidden email]>    wrote:
>>>>> Quoting Scott Marlow<[hidden email]>:
>>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Brian Stansberry
We already expose a JMX connector. And we will expose all the management
resources as mbeans. So all our management resources will be available
via JMX, as will be any stuff that 3rd parties choose to put in JMX.

So the only issue is whether we provide a simple JMX gateway resource to
provide access to 3rd party JMX stuff via the domain management API and
thus the CLI. I already said I have no objection to that. It's not a
priority that I want to allocate any resources to though in the next few
months; we have a lot of tasks to get done.

On 8/19/11 2:06 PM, Eduardo Martins wrote:

> 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<[hidden email]>  wrote:
>>
>>
>> ________________________________
>>
>> From: "Brian Stansberry"<[hidden email]>
>> To: [hidden email]
>> 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<[hidden email]>
>>>   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,<[hidden email]>      wrote:
>>>>>> Quoting Scott Marlow<[hidden email]>:
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Brian Stansberry
In reply to this post by Eduardo Martins
The concern about an "excuse" is not about 3rd parties; they can do as
they wish. It is about our own projects that we integrate as subsystems
installing mbeans in random locations in JMX and considering their
management integration work done.

On 8/19/11 1:46 PM, Eduardo Martins wrote:

> With easy extension I mean to be possible for people to add other not
> so basic JMX features, to build on top of it, if they really need it.
>
> Now with respect to this stuff becoming an excuse to not use the
> management API... I think even 3rd party systems will use it, all
> depends on what people get from it, but note they will be developing
> on top of something proprietary, that is a "no way" for some 3rd
> parties. But for a start, having basic JMX features in the management
> tools is a must, very important for easier migrations, not only from
> older JBoss AS versions, but also from competing products.
>
> Expose the bait... get people in the shop, then sell what really
> matters, otherwise you risk not sell anything at all.
>
> -- Eduardo
> ..............................................
> http://emmartins.blogspot.com
> http://redhat.com/solutions/telco
>
>
>
> On Fri, Aug 19, 2011 at 6:52 PM, Brian Stansberry
> <[hidden email]>  wrote:
>> 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<[hidden email]>    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,<[hidden email]>      wrote:
>>>>>> Quoting Scott Marlow<[hidden email]>:
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: JMX [was: Dear subsystem owners/components leads ....]

Andrig Miller
In reply to this post by Eduardo Martins
I understand where you are coming from, but if JMX was actually able to do everything we needed from a management perspective, we would have built the new management API based on it.  The fact is, it doesn't meet the need.  Brian Stansberry even looked at this as a possibility early in the development cycle.  I remember having a conversation about it on our bi-weekly Andiamo call.

We need one supportable management API, not two, and one that actually works for the complexity involved in all the use cases we have to support.

Yes, the transition will be a hard one, but its a necessary step we have to take in order to actually meet customers management needs.  This has been a long time in the works, and this has all been considered.

Andy


From: "Eduardo Martins" <[hidden email]>
To: "Andrig Miller" <[hidden email]>
Cc: "Brian Stansberry" <[hidden email]>, [hidden email]
Sent: Friday, August 19, 2011 1:06:49 PM
Subject: Re: [jboss-as7-dev] JMX [was: Dear subsystem owners/components leads ....]

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 <[hidden email]> wrote:

>
>
> ________________________________
>
> From: "Brian Stansberry" <[hidden email]>
> To: [hidden email]
> 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<[hidden email]>
>>  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,<[hidden email]>    wrote:
>>>>> Quoting Scott Marlow<[hidden email]>:
>>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

Carlo de Wolf
In reply to this post by Heiko Braun
How can an user deploy a custom build component that exposes user
defined management operations?

For example a custom SLSB pool implementation.

Carlo

On 07/14/2011 12:25 PM, Heiko Braun wrote:

>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

jtgreene
Administrator
On 8/22/11 3:29 AM, Carlo de Wolf wrote:
> How can an user deploy a custom build component that exposes user
> defined management operations?
>
> For example a custom SLSB pool implementation.

Awhile back we talked about having the ability for a deployment to
register with the management API for runtime server only operations. I
think that's still a good option.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dear subsystem owners/components leads ....

Brian Stansberry
Yes, that's how it should be done. For custom pools, presumably the
standard pools we ship could do this via an SPI provided by the EJB3
subsystem; custom pool impls could implement the same SPI.

On 8/22/11 9:28 AM, Jason T. Greene wrote:

> On 8/22/11 3:29 AM, Carlo de Wolf wrote:
>> How can an user deploy a custom build component that exposes user
>> defined management operations?
>>
>> For example a custom SLSB pool implementation.
>
> Awhile back we talked about having the ability for a deployment to
> register with the management API for runtime server only operations. I
> think that's still a good option.
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev