Just to add my 2c again....
I don't think this is really related to how a MBean is implement.
Standard, Dynamic, Model or Open MBeans may all be used in
a JBoss MBeanServer and each may either be a JBoss service
or not.
The point is that JBoss should only call init() on MBeans
that are JBoss services - regardless of how they are implemented.
Presence of an init() method is not really a good enough
test for a JBoss service, it is a bit of a universal method name
to claim as a unique JBoss service.
Julians idea of an isAJBossServer() method is good (except that
I prefer the name isJBossServer() )
If JBoss wants to allow components to use MBeans to manage themselves
OR if you want JBoss components are to be used in larger JMX frameworks
then you must do something to detect JBoss MBeans and only
attempt to auto manage them.
cheers
Julian Gosnell wrote:
> --- Juha-P Lindfors <[EMAIL PROTECTED]> wrote:
>
>>
>>On Wed, 11 Apr 2001, Julian Gosnell wrote:
>>
>>>AFAIK, the advantage of Dynamic MBeans is that
>>>
>>they
>>
>>>are not statically constrained by inheritance and
>>>
>>may
>>
>>>vary their interfaces dynamically at run time.
>>>
>>>Both of these demonstrate the inadequacy of simply
>>>checking the inheritance of a potential Service
>>>
>>MBean
>>
>>Actually I don't believe this to be true. Dynamic
>>MBeans can determine
>>their management interface at runtime, for example
>>by reading an XML
>>file. This allows the management interface to be
>>changed without
>>recompiling. But they should not vary the interface
>>during their life
>>
>
> OK - I agree - my mistaken assumption. The way they
> are coded leaves a gap which MAY be exploited to do
> this, however the JMX spec states DynamicMBeans SHOULD
> not do so.
>
>
>>time. A management application can expect the
>>management interface to stay
>>the same during the life time of the MBean, once it
>>has retrieved it from the
>>agent. The agent is not required to enforce this
>>static interface, so it
>>is possible to build dynamic mbeans that do vary
>>their interfaces but this
>>can only be done with proprietary management
>>applications. Compliant JMX
>>applications can't be expected to work.
>>
>>
>
>>So I still think checking for the Service interface
>>is good enough for
>>solving the Jetty integration problem. For fancier
>>life cycle management,
>>I think Stacy already has the base work done (via
>>xmlets) and that is a
>>very interesting work, but not required for this
>>particular problem at
>>hand :)
>>
>>
>
> I still think that it should be up to a DynamicMBean
> at runtime whether or not it wishes to be managed by
> ControlService (otherwise what is the point of being a
> DynamicMBean?).
>
> If you simply look at it's inheritance you constrain
> this decision to compile time.
>
> If you configure it in a file you constrain it to
> deploy-time.
>
> What is more complicated, less efficient or wrong
> about making the decision at run-time ?
>
> I think I'll rest my case here and wait to see what
> actually gets implemented.
>
> I look forward to seeing my JettyMBeans working
> harmoniously with JBossMBeans.
>
>
> Thanks everyone for all the input. I hope we didn't
> consume to much bandwidth.
>
> Catch you all later,
>
>
> Jules
>
>
>
>>-- Juha
>>
>>
>>
>>_______________________________________________
>>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
