Hi all,
I'm the author of the Jetty MBeans, so I may be able to explain
them a bit more.
Jetty is used in several different JXM frameworks, of which JBoss is
only one of them.
JMX is meant to be a extensible managment framework, so you should not
try to constrain the number or type of MBeans that register. If you
don't know what they are - some other agent or MBean may! In the
case of JBoss, the extra Jetty MBeans can be examined via the
HtmlAdaptor agent and the Jetty configuration browsed and/or changed.
While observing registrations of MBeans and taking actions as a
result is a common JMX pattern, you have to be careful that your
agent knows that it is OK to call a method. Firstly you need
to check that the method exists. Really you should check
that the object is of the type you think it is - just because
it has an init method does not mean that it implements the
JBoss lifecycle,
In an other JMX framework that Jetty is used in, either the
object name or the object class is checked against a XML
configuration file before any on-registration actions are taken.
JBoss must be able to be deployed in any JMX framework, so
it cannot make assumptions that it is the only game in town.
Note that Jetty uses Model MBeans rather than StandardMBeans
so that additional meta information may be includeded about the
methods and attributes. You will see that when viewing the
Jetty MBeans in the HtmlAdaptor agent, the pop up text contains
real information that it taken from a resource bundle in Jetty.
cheers
Julian Gosnell wrote:
> I'm getting the stacktrace because I'm catching an
> Error and printing it out in my code.
>
> I cannot add the lifecycle methods to every MBean
> because they are 3rd party, created dynamically and
> not under my control.
>
> I don't think it is enough to simply ignore these
> Errors. The fact that JettyMBeans do not implement
> init() is a direct result of their ignorance of the
> JBossService lifecycle. They _DO_ have
> start()/stop()/destroy(), but these are part of a
> Jetty lifecycle and not intended for use by JBoss. If
> JBoss calls lifecycle methods on MBeans that are
> created, owned and managed internally by Jetty the
> results would not be good.
>
> We should be considering how a number of MBeans can
> register with the JBoss MBeanServer, some of which
> indicate that they wish their lifecycle managed by
> JBoss, and some of which (the default) don't
>
> Jules
>
> --- David Jencks <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> Well, it looks to me like he has thrown the
>> NoSuchMethodException himself
>> in his ModelMBeanImpl. This exception dexcends from
>> Exception, thus is not
>> a reflection exception, and isn't caught by any of
>> the exception
>> handlers/ignorers.
>>
>> I don't yet understand what ModelMBeans are for...
>> but if he changed the
>> missing method handling to match that of line 1620
>> of the MBeanServerImpl,
>> the problems might go away.
>>
>>
>> Further posts from Scott Stark and Marc Fleury make
>> me think this may be
>> difficult to impossible. If so, we could instead
>> change ServiceControl to
>> ignore MethodNotFoundExceptions as well as
>> ReflectionExceptions. e.g.
>> around line 67
>>
>> } catch (ReflectionException e)
>> {
>> // Not a service - ok
>> }
>> catch (NoSuchMethodException e) {
>> //Not a service - also ok
>> } catch (RuntimeMBeanException e)
>>
>>
>> Personally I am inclined to suggest putting empty
>> methods for the
>> nonexistent operations in every mbean. I don't
>> entirely understand why
>> this isn't in the mbean spec.
>>
>> David Jencks
>>
>> On 2001.04.10 21:12:52 -0400 [EMAIL PROTECTED]
>> wrote:
>>
>>> Hey,
>>>
>>>
>>>
>>>> There shouldn't even be a log msg about the
>>>
>> missing method since if you
>>
>>> invoke a
>>>
>>>> method that does not exist on an MBean you will
>>>
>> get a
>>
>>> ReflectionException and
>>>
>>>> these are simply ignored. All MBeans show up on
>>>
>> the management page
>>
>>> because
>>>
>>>> this page is about MBeans and cares nothing
>>>
>> about service abstractions.
>>
>>> Scott, that is what I thought too. But how is he
>>
>> getting this
>>
>>> stacktrace:
>>>
>>> [Jetty]
>>> java.lang.NoSuchMethodException: init()
>>> at
>>
> com.mortbay.Jetty.JMX.ModelMBeanImpl.invoke(ModelMBeanImpl.java)
>
>>> at
>>>
>>
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
>
>>> at
>>>
>>
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
>
>>> at
>>
> org.jboss.util.ServiceControl.init(ServiceControl.java:59)
>
>>> at java.lang.reflect.Method.invoke(Native Method)
>>> at
>>>
>>
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
>
>>> at
>>>
>>
> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
>
>>> at org.jboss.Main.<init>(Main.java:202)
>>> at org.jboss.Main$1.run(Main.java:107)
>>> at
>>
>> java.security.AccessController.doPrivileged(Native
>> Method)
>>
>>> at org.jboss.Main.main(Main.java:103)
>>>
>>>
>>>
>>>> _______________________________________________
>>>> Jboss-development mailing list
>>>> [EMAIL PROTECTED]
>>>>
>>>
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>>>
>>> _______________________________________________
>>> Jboss-development mailing list
>>> [EMAIL PROTECTED]
>>>
>>
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>>
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>>
>
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development