You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Huw Roberts <hu...@apache.org> on 2002/08/06 06:35:24 UTC
Management MBean Interfaces - Stay or go?
There are two ways to expose management information now:
1) use the phoenix-mx tags to markup blocks/apps/components as
management-enabled and then specify the methods and attributes to export
2) have the class implement a management interface (usually called *MBean),
and pass that into the export() method
Method 2) is supported, but at least in my opinion, no longer the best way
to go. Can I remove them and then mark-up the base classes with the
management info? Or will that break a lot of code?
If its a problem, I can markup the MBean interfaces instead. The result is
the same, I just think less classes is better if we can get there.
- Huw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Management MBean Interfaces - Stay or go?
Posted by Paul Hammant <Pa...@yahoo.com>.
Huw,
> The only way removing the MBean interfaces will break anything is if
> some client code takes special action based on the *MBean class. For
> example, client code might do a check to see if a managed object is an
> instance of ApplicationMBean and then use that fact to decide what to
> display.
>
> Also, I'm not removing support for this functionality, I'm just
> changing it in phoenix to what i consider the 'standard' (simpler)
> pattern.
OK, if this is additional functionality, then I'd prefer to see the beta
ship without it. It is not that revolutionary to consider the negative
impact on the user base.
Thoughts?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Management MBean Interfaces - Stay or go?
Posted by Huw Roberts <hu...@apache.org>.
At 07:05 AM 8/6/02 +0100, you wrote:
>Huw,
>
>In effect you are suggesting that we need not bother with interfaces
>suffixed with MBean? You are saying that with markup tags only, you can
>generate dynamically a JMX presence for a Phoenix hosted app?
Yes - basically instead of looking at the interface to determine what
methods to export, it uses the tags instead.
>I'm all for that, if true. By code breakage you mean, through avalon-apps
>etc?
The only way removing the MBean interfaces will break anything is if some
client code takes special action based on the *MBean class. For example,
client code might do a check to see if a managed object is an instance of
ApplicationMBean and then use that fact to decide what to display.
Also, I'm not removing support for this functionality, I'm just changing it
in phoenix to what i consider the 'standard' (simpler) pattern.
>>There are two ways to expose management information now:
>>
>>1) use the phoenix-mx tags to markup blocks/apps/components as
>>management-enabled and then specify the methods and attributes to export
>>2) have the class implement a management interface (usually called
>>*MBean), and pass that into the export() method
>>
>>Method 2) is supported, but at least in my opinion, no longer the best
>>way to go. Can I remove them and then mark-up the base classes with the
>>management info? Or will that break a lot of code?
>>
>>If its a problem, I can markup the MBean interfaces instead. The result
>>is the same, I just think less classes is better if we can get there.
>>
>>- Huw
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>
>
>
>
>--
>To unsubscribe,
>e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Management MBean Interfaces - Stay or go?
Posted by Paul Hammant <Pa...@yahoo.com>.
Huw,
In effect you are suggesting that we need not bother with interfaces
suffixed with MBean? You are saying that with markup tags only, you can
generate dynamically a JMX presence for a Phoenix hosted app?
I'm all for that, if true. By code breakage you mean, through
avalon-apps etc?
- Paul
> There are two ways to expose management information now:
>
> 1) use the phoenix-mx tags to markup blocks/apps/components as
> management-enabled and then specify the methods and attributes to export
> 2) have the class implement a management interface (usually called
> *MBean), and pass that into the export() method
>
> Method 2) is supported, but at least in my opinion, no longer the best
> way to go. Can I remove them and then mark-up the base classes with
> the management info? Or will that break a lot of code?
>
> If its a problem, I can markup the MBean interfaces instead. The
> result is the same, I just think less classes is better if we can get
> there.
>
> - Huw
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Management MBean Interfaces - Stay or go?
Posted by Huw Roberts <hu...@apache.org>.
At 04:06 PM 8/6/02 +1000, you wrote:
>At 09:35 PM 8/5/2002 -0700, you wrote:
>>There are two ways to expose management information now:
>>
>>1) use the phoenix-mx tags to markup blocks/apps/components as
>>management-enabled and then specify the methods and attributes to export
>>2) have the class implement a management interface (usually called
>>*MBean), and pass that into the export() method
>>
>>Method 2) is supported, but at least in my opinion, no longer the best
>>way to go. Can I remove them and then mark-up the base classes with the
>>management info? Or will that break a lot of code?
>
>Are you talking about internal phoenix components or blocks hosted by
>Phoenix? If it is internal phoenix components then go for it. However if
>you are talking about blocks then I would not like to see raw interfaces
>become unsupported.
>
>The main reason they were added was to allow users to do something like
>the following;
>
>MBeanServer mBeanServer = ....;
>ObjectName name = ...;
>
>FooMBean foo = (FooMBean)MBeanProxy.lookup( name, mBeanServer,
>FooMBean.class );
>
>foo.doStuff()
>foo.getValue()
>
>etc.
>
>They could treat the managed objects as normal objects rather than going
>directly through MBeanServer. So I would like to see them still supported.
>
>However if you want to make some of the apps/components hosted in avalon
>use this style then go for it. FWIW many other projects actually
>dynamically generate the FooMBean interface from xdoclet like decorations
>so that may be a long term direction.
>
>Personally I would prefer to keep management stuff isolated to MBean
>interfaces and or proxies when/if you implement that but up to you.
>
>However I would prefer to keep the ability to manage via interfaces (and
>corresponding entrys in .xinfo files).
>
>Thoughts?
Ok, now i've changed my mind, at least for now. :).
The only thing in question right now is what the ''standard pattern" is
going to be. Users have two choices:
(a) markup the managed class with phoenix-mx tags directly.
(b) have the managed class implement a management interface and mark that up.
Both of these will work, its just a question of which is the one you would
recommend to someone (which we'll be doing in the docs). For now the
recommendation will be to put management info in an MBean interface.
Automagically generating the interfaces from the descriptors sounds like a
great way to go, but I don't see that happening in this release. If/when
that happens we can change the standard from (b) to (a).
Sound ok?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Management MBean Interfaces - Stay or go?
Posted by Peter Donald <pe...@apache.org>.
At 09:35 PM 8/5/2002 -0700, you wrote:
>There are two ways to expose management information now:
>
>1) use the phoenix-mx tags to markup blocks/apps/components as
>management-enabled and then specify the methods and attributes to export
>2) have the class implement a management interface (usually called
>*MBean), and pass that into the export() method
>
>Method 2) is supported, but at least in my opinion, no longer the best way
>to go. Can I remove them and then mark-up the base classes with the
>management info? Or will that break a lot of code?
Are you talking about internal phoenix components or blocks hosted by
Phoenix? If it is internal phoenix components then go for it. However if
you are talking about blocks then I would not like to see raw interfaces
become unsupported.
The main reason they were added was to allow users to do something like the
following;
MBeanServer mBeanServer = ....;
ObjectName name = ...;
FooMBean foo = (FooMBean)MBeanProxy.lookup( name, mBeanServer,
FooMBean.class );
foo.doStuff()
foo.getValue()
etc.
They could treat the managed objects as normal objects rather than going
directly through MBeanServer. So I would like to see them still supported.
However if you want to make some of the apps/components hosted in avalon
use this style then go for it. FWIW many other projects actually
dynamically generate the FooMBean interface from xdoclet like decorations
so that may be a long term direction.
Personally I would prefer to keep management stuff isolated to MBean
interfaces and or proxies when/if you implement that but up to you.
However I would prefer to keep the ability to manage via interfaces (and
corresponding entrys in .xinfo files).
Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>