If a DynamicMBean does not implement the contract
correctly then by definition it is not a JBoss Service
and does not require management.
checking isA(org.jboss.util.Service) will work on
standard MBeans, but not necessarily on DynamicMBeans.
Just because a DynamicMBean implements Service does
not mean that it publishes it via JMX. Alternatively
it may publish an interface that looks like Service
via JMX but implement it differently (If I added an
init() method to the Jetty lifecycle it would look the
same).
I maintain that the way to be sure if an MBean intends
to be used as a JBoss service is for it to be explicit
and unambigous about this intention.
Inheriting from org.jboss.util.Service is so.
Publishing a method isAJBossService() is so.
In order to save using different tests for Standard
and Dynamic MBeans you could simply add
isAJBossService() to org.jboss.util.Service and test
for this one thing.
This would have the additional advantage of allowing a
Service that does inherit from Service to opt out of
the JBoss lifecycle by returning 'false'. Furthermore
it would allow dynamic MBeans to make the decision
dynamically, instead of statically, which on further
consideration I think is probably the best argument
for the method. DynamicMBeans are allowed to vary
their interfaces during their lifetime. This may well
impact on the availability of their JBoss Service
interface, so they need to be able to indicate this to
JBoss.
I don't think you can achieve this same dynamicity and
simplicity by checking inheritance or naming schemes.
Anyone ?
Jules
--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hey ppl,
>
> On Wed, 11 Apr 2001, Julian Gosnell wrote:
>
> > I think that Services should publish 'boolean
> > isAJBossService() {return true;}' method.
> >
> > This could be implemented in MBeanServiceSupport
> for
> > standard Service MBeans. Dynamic Service MBeans
> would
> > have to do it themselves.
> >
>
> Yes sure, but what if DynamicMBean doesn't fullfill
> this contract or
> implements it poorly? DMBean will probably log
> NoSuchMethodException or
> even something worse and we will have bunch of
> "cosmetic" (thanks
> Scott) stacktraces/exceptions.
>
> I still don't see anything wrong with type check for
> org.jboss.util.Service.
>
> Vladimir
>
>
> > You could use naming, but then you constrain
> naming
> > conventions, which may upset someone else.
> >
> > Just my 1p's-worth,
> >
> > Jules
> >
> > --- Scott M Stark <[EMAIL PROTECTED]>
> > wrote:
> > > The Jetty mbean is logging the exception itself
> as a
> > > warning and then it
> > > is throwing the proper ReflectionException. The
> > > issue is that ServiceControl
> > > is invoking JBoss Service methods on any mbean
> that
> > > registers with the
> > > MBeanServer. There needs to be a way to tell
> > > ServiceControl that categories
> > > of mbean should not be treated as candidate
> JBoss
> > > services. I'm saying this
> > > is trivial to do using a domain naming
> convention
> > > and a configurable NotificationFilter
> > > based on mbean domain names.
> > >
> > > If anyone has a better way achieving this speak
> up.
> > >
> > >
> > > ----- Original Message -----
> > > From: "David Jencks" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, April 10, 2001 10:30 PM
> > > Subject: Re: [JBoss-dev] Nested JMX Service
> > > Groups...??!
> > >
> > >
> > > > 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
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
>
>
> _______________________________________________
> 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
