12:25 p.m.
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
2:59 p.m.
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
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4:58 p.m.
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
> 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
5:35 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
Quoting Scott Marlow <smarlow(a)redhat.com>:
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
6:19 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
On 8/19/11 10:35 AM, ssilvert(a)redhat.com wrote:
Quoting Scott Marlow<smarlow(a)redhat.com>:
> 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
6:22 p.m.
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
6:29 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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, <ssilvert(a)redhat.com> wrote:
Quoting Scott Marlow <smarlow(a)redhat.com>:
> 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
6:52 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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,<ssilvert(a)redhat.com> wrote:
> Quoting Scott Marlow<smarlow(a)redhat.com>:
>> 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
7:02 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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 <david.lloyd(a)redhat.com> 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,<ssilvert(a)redhat.com> wrote:
>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>> 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
7:52 p.m.
New subject: 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<david.lloyd(a)redhat.com> 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,<ssilvert(a)redhat.com> wrote:
>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>> 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
8:14 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
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<david.lloyd(a)redhat.com> 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,<ssilvert(a)redhat.com> wrote:
>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>> 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
8:46 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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
<brian.stansberry(a)redhat.com> 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<david.lloyd(a)redhat.com>
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,<ssilvert(a)redhat.com> wrote:
>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>> 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
9:06 p.m.
New subject: 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 <anmiller(a)redhat.com> wrote:
________________________________
From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
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<david.lloyd(a)redhat.com>
> 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,<ssilvert(a)redhat.com> wrote:
>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>> 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
9:34 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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<anmiller(a)redhat.com> wrote:
>
>
> ________________________________
>
> From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
> 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<david.lloyd(a)redhat.com>
>> 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,<ssilvert(a)redhat.com> wrote:
>>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>>> 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
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:38 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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
<brian.stansberry(a)redhat.com> 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<david.lloyd(a)redhat.com>
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,<ssilvert(a)redhat.com> wrote:
>>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>>> 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
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
10:12 p.m.
New subject: JMX [was: Dear subsystem owners/components leads ....]
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
----- Original Message -----
From: "Eduardo Martins" <emmartins(a)gmail.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "Brian Stansberry" <brian.stansberry(a)redhat.com>,
jboss-as7-dev(a)lists.jboss.org
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
<anmiller(a)redhat.com>
wrote:
>
>
> ________________________________
>
> From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
> 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<david.lloyd(a)redhat.com>
>> 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,<ssilvert(a)redhat.com> wrote:
>>>>> Quoting Scott Marlow<smarlow(a)redhat.com>:
>>>>>> 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
>
>
10:29 a.m.
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
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4:28 p.m.
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
4:47 p.m.
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
4639
days inactive
4678
days old
18 comments
9 participants
participants (9)
-
Andrig Miller -
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
Eduardo Martins -
Heiko Braun -
Jason T. Greene -
Scott Marlow -
ssilvert＠redhat.com