10:56 a.m.
I don't think we should use JMX as a bridging technology for exposing
the management model. However, that doesn't rule out beginning with JMX
integration as a means of dividing up the overall task, if that better
suits Ioannis.
To me, using JMX for exposing the management model basically means:
1) Writing the core subsystem stuff. I have no problem with this, since
it's of course necessary no matter what. :)
2) Writing JMX-to-SNMP adaptor logic as well as configuration schema for
letting the user configure this in the subsystem configuration. I have
no problem with this. Users can deploy mbeans to the server, so this is
a useful feature, regardless of how the core management model is exposed.
3) Adding stuff to our standard configuration files, or examples to our
standard documentation, that shows using the JMX-configuration stuff
from 2) to expose the management model. I am opposed to this,
particularly the standard configuration files. It basically promotes
using a work-around to an incomplete feature as the standard way of
doing something. Once that kind of thing gets out into the wild, we end
up having to live with it forever. Better IMHO is for us to get the
feature fully complete.
As for how to program against the domain model, see:
1) https://docs.jboss.org/author/display/AS72/Extending+JBoss+AS+7
2)
https://docs.jboss.org/author/display/AS72/Admin+Guide#AdminGuide-Managem...
The latter has a lot of basic conceptual stuff. There are two sections,
6.4.1 and 6.4.2 which relate to obtaining an instance of
ModelControllerClient, which is the interface implemented by classes
that talk to the core controller class that manages the model (the
ModelController.) However, those 2 sections are written from the point
of view of external clients who want to do things remotely, which is not
what would be done here. Inside the AS you obtain a
ModelControllerClient by injecting a reference to the ModelController
inside a service installed by your subsystem, and then invoking the
ModelController method:
/**
* Create an in-VM client.
*
* @param executor the executor to use for asynchronous operation
execution
* @return the client
*/
ModelControllerClient createClient(Executor executor);
See usages in the AS codebase of
org.jboss.as.server.Services.JBOSS_SERVER_CONTROLLER for examples of this.
On 9/10/12 7:18 AM, Jean Deruelle wrote:
Hi Brian,
Do you think we could do it in 2 steps (see below) so that Ioannis
Andreadakis may have an easier time to contribute the migration of the
SNMP Adaptor to AS7 ?
First make the old SNMP Adaptor a subsystem of JBoss AS7 that would
still use JMX (what configuration changes would be needed to expose the
domain model as JMX ?) and then a second step to allow the SNMP Adaptor
to map directly to the AS7 domain model (is there any documentation and
API on how to effectively use/code against the AS7 Domain model
programatically ?)
Thx in advance
BR
Jean
On Fri, Sep 7, 2012 at 2:27 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
On 9/7/12 7:19 AM, Dimitris Andreadis wrote:
> The old adapter had also get/set functionality in addition to
notifications mapping.
>
Very good point. So that removes the rationale for saying "first do
domain mode notifications and then do SNMP."
> I suppose you can still talk to JMX MBeans using Kabir's bridge,
which maps the domain model
> to JMX, no?
>
> Or else go for deeper integration to the domain model.
>
This. :) The domain model is only exposed via JMX if the jmx subsystem
is configured that way. So having an snmp subsystem count on that path
being open IMHO would be the wrong approach.
> /D
>
> On 06/09/2012 22:52, Brian Stansberry wrote:
>> An SNMP subsystem would be nice, so yes, help on that would be
welcome.
>>
>> However, the old SNMP adaptor adapted JMX notifications to SNMP.
An AS7
>> solution can't really rely on that, since most management
activity in
>> the AS doesn't result in JMX notifications. JMX just isn't at
the core
>> of the AS the way it was in JBoss 4. But, at this point we
haven't added
>> a notification capability to the AS7 management stuff. We want to do
>> that[1], but haven't been able to get to it, and may not for a while
>> unless someone from the community can help push it.
>>
>> As for the method for getting involved, see
>> https://community.jboss.org/wiki/HackingOnAS7 for basics. Beyond
that,
>> the thing to do is to have design discussions on this list, as
you have
>> just done. :)
>>
>> I see from the forum thread you linked that you are in contact
with Jean
>> Deruelle, who looks to have done the bulk of the work on the
unfinished
>> port. I've bcc'd Bartosz Baranowski and Thomas Hauser who also
did some
>> work there, in case they have some comments.
>>
>> [1] https://issues.jboss.org/browse/AS7-370
>>
>> On 9/6/12 4:04 AM, Ioannis Andreadakis wrote:
>>> Hello,
>>>
>>> I am currently working with the task of creating an SNMP
adaptor for
>>> AS7. So far I have found that there was one developed
>>> <https://community.jboss.org/wiki/JBossSNMPAdapter> for JBoss
4, and I
>>> also found a discussion here
<https://community.jboss.org/thread/147085>
>>> where someone has taken the old code and started making
compatible with
>>> 7
>>>
<http://code.google.com/p/commscale/source/list?repo=snmp-adaptor&name...
>>> but work is far from finished.
>>> I will probably try to port the old code to Jboss 7, what I
would like
>>> to ask is if you are interested in me contributing this work
and if so
>>> if you would suggest an appropriate method to do that.
>>>
>>> Kind Regards
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@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 <mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat