You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Greg Wilkins <gr...@mortbay.com> on 2003/08/12 15:07:33 UTC
Dynamic MBeans. Was: Kernel Architecture
James Strachan wrote:
>>> An interface based MBean is just a naming convention. There is no
>>> tying to anything. Indeed there's not even a dependency on JMX never
>>> mind any other container API. Then the container is totally free to
>>> go in whatever direction it wishes.
>>
>>
>> But by creating (and calling) them MBeans, you are tying it down to a
>> naming convention expected by JMX which may confuse the issue later.
>
>
> Why? Whats confusing about it? Why would inventing yet-another-API be
> any less confusing?
Why can't we go for a totally dynamic MBean model?
Ie - for a given FooService, why do we need to write a FooServiceMBean
interface that just has the methods we wish to expose?
This is the simplest form of MBean, but contains no meta data to
describe that MBean - which has to be placed in an xml file elsewhere.
I think we should be able to just create the FooService objects
and then describe any MBeans we want for them in XML - describing
the methods and the meta data in one spot.
If we decide not to use MBeans, then we still have our FooService
objects and we have no FooServiceMBean objects clutering up the
repository.
If we decide to use MBeans - it means that we will have fewer
undocumented MBeans without real meta data. We can also expose
more of an object simply by changing the MBean descriptor file.
--
Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
James Strachan wrote:
>> Why can't we go for a totally dynamic MBean model?
>
>
> We absolutely could. I was trying to just come up with a simple
> convention component authors could follow - though we should be flexible.
>
>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
>
>
> No reason why we couldn't do that. Could use XDoclet or an XML config
> file or some clever build process to generate the MBean or dynamic
> MBeans whatever.
Hmmm. Avalon Pheonix currently does this. We might be able to adapt what
is there and use it here.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 14:20 Europe/London, James Strachan wrote:
>
> On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
>>>> But by creating (and calling) them MBeans, you are tying it down to
>>>> a naming convention expected by JMX which may confuse the issue
>>>> later.
>>> Why? Whats confusing about it? Why would inventing yet-another-API
>>> be any less confusing?
>>
>> Why can't we go for a totally dynamic MBean model?
>
> We absolutely could. I was trying to just come up with a simple
> convention component authors could follow - though we should be
> flexible.
What about creating an interface, say, ManagedComponent, that component
authors could implement? Then we can move any JMX/MBean specific
behavoir into that interface (or an AbstractManagedComponent abstract
class) and let developers subclass that?
A convention like XxxComponent or XxxService may also be more
meaningful to developers. Are there any other major types of code in a
server? XxxAgent, Xxx??? If we can have placeholders for these, then
future components can be described as one (many?) of these.
>> Ie - for a given FooService, why do we need to write a FooServiceMBean
>> interface that just has the methods we wish to expose?
>
> No reason why we couldn't do that. Could use XDoclet or an XML config
> file or some clever build process to generate the MBean or dynamic
> MBeans whatever.
Yes, having an externalised/automatically generated MBean is probably a
good way to go.
>> I think we should be able to just create the FooService objects
>> and then describe any MBeans we want for them in XML - describing
>> the methods and the meta data in one spot.
>>
>> If we decide not to use MBeans, then we still have our FooService
>> objects and we have no FooServiceMBean objects clutering up the
>> repository.
>
> I'm cool with alternative forms of getting to the same place. i.e.
> however the MBeans are written - whether they are just POJOs or beans
> and we adorn them to be MBeans or we follow the MBean interface or we
> use some XML deployment descriptor for the MBean metadata - I'm easy.
> It can then be the developers choice.
>
> I personally quite like the MBean interface idea as it makes
> refactoring easier and your code has no dependencies on JMX - though
> we should be able to use better / simpler mechanisms for this.
IMHO the naming convention of MBean does tie it down, though; from the
JMX spec:
JMX_1-2 p37: "The name of an MBean's Java interface is formed by adding
the 'MBean' suffix to the MBean's fully qualified Java class name. For
example, the Java class MyClass would implement the MyClassMBean
interface"
Not having the naming convention would then make it clearer if MBeans
were not to be used later. However, the principles of still having the
getters/setters is a clear and easy step for developers to be able to
interact with it, in whatever means.
>> If we decide to use MBeans - it means that we will have fewer
>> undocumented MBeans without real meta data. We can also expose
>> more of an object simply by changing the MBean descriptor file.
>
> Agreed.
Externalising the MBean descriptors (and the subsequent automatically
generated code) might be a way of implementing security as an aspect on
top of that?
Alex.
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?
We absolutely could. I was trying to just come up with a simple
convention component authors could follow - though we should be
flexible.
> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?
No reason why we couldn't do that. Could use XDoclet or an XML config
file or some clever build process to generate the MBean or dynamic
MBeans whatever.
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
Agreed - though at least it works :). i.e. its the minimum requirement
for a component/service author.
> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
I'm cool with alternative forms of getting to the same place. i.e.
however the MBeans are written - whether they are just POJOs or beans
and we adorn them to be MBeans or we follow the MBean interface or we
use some XML deployment descriptor for the MBean metadata - I'm easy.
It can then be the developers choice.
I personally quite like the MBean interface idea as it makes
refactoring easier and you're code has no dependencies on JMX - though
we should be able to use better / simpler mechanisms for this.
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
Agreed.
James
-------
http://radio.weblogs.com/0112098/
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
On 8/12/03 06:10 PM Berin Loritsch <bl...@apache.org> wrote:
> Jens Schumann wrote:
>
>> I agree with you. However I still don't get the point why relying on JMX is
>> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
>> is a specification and it is up to you to implement it.
>
> Umm, I don't recall saying anything about jakarta-commons*. I use code from
> there, and in general it is usually pretty good stuff.
Just an analogy. The only reason I switched from silently reading this ML to
posting a few comments is that I see a certain resistance to certain topics
just because religious reasons or something (and I don't say you did that;),
while other areas are out of discussion. Jakarta-commons* is one of those,
and to be honest, jakarta-commons* is a one way street with no return. And
it is not just me who believes in that;).
>> See above, it is a specification. And I don't say JMX based is the only
>> solution. But I believe most people here on the list talk about the
>> instrumentation level only.
>
> I understand that JMX is a specification. The only major real damage that
> I see here is one of the golden hammer. The temptation with any new tool
> is to go hog wild with it. I am usually much more conservative, and introduce
> the tool where I think it would help. IOW, I start small. Since JMX already
> has a place where it lends a big help, I am resistent to endorsing a path
> where
> it is the *only* solution. As long as we can make it *one* solution out of
> many, I will happily shut my trap.
>
> Since you mentioned moving back and forth between JMX enabled and JMX
> based is bad, that is yet another red flag that maybe we don't want to
> go down that road. But that is my conservative side talking. I'm not
> going to get in the way if you hell bent on going that direction. I'm
> just trying to find some balance here.
And I am on the other side;). JMX is there a couple of years. And I have to
admit that I love the power of JMX in loosely coupled component based
systems. While following the discussion here I felt some pain reading about
instrumentation only, so please consider taking a look at the agent services
provided through JMX. If they are worth nothing just ignore my posts.
In the end raising the red flag is valid, since switching back to JMX
enabled will be painful to impossible, as it is for switching to a JMX based
solution at some point.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>Von: Berin Loritsch <bl...@apache.org>
>>Antworten an: geronimo-dev@incubator.apache.org
>>Datum: Tue, 12 Aug 2003 11:39:44 -0400
>>An: geronimo-dev@incubator.apache.org
>>Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>>
>>Jens Schumann wrote:
>>
>>The thing is that there are certain compromises in the all-in-one box that
>>you have no control over. Usually the manufacturers of these boxes can only
>>spend money on one part of it, and they skimp on the rest. So it may have
>>a good tape player, but the CD player sucks (or vice versa).
>
>
> I agree with you. However I still don't get the point why relying on JMX is
> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
> is a specification and it is up to you to implement it.
Umm, I don't recall saying anything about jakarta-commons*. I use code from
there, and in general it is usually pretty good stuff.
>
>
>>>In the end it all boils down to whether a system is JMX enabled or JMX
>>>based. Interestingly most projects I have seen moved to JMX enabled at some
>>>stage, since too much stuff was maintained in parallel. However the
>>>transition from one to the other model is something you should avoid (just
>>>take a look at tomcat 5).
>>
>><shudder/>
>>
>>Seriously though, I would much prefer to have JMX enabled than JMX based,
>>as we can have more fine tuned control where we need it. The JMX dynamic
>>classloading might be something causing problems instead of solving them.
>>If that happens, what is your recourse?
>
>
> See above, it is a specification. And I don't say JMX based is the only
> solution. But I believe most people here on the list talk about the
> instrumentation level only.
I understand that JMX is a specification. The only major real damage that
I see here is one of the golden hammer. The temptation with any new tool
is to go hog wild with it. I am usually much more conservative, and introduce
the tool where I think it would help. IOW, I start small. Since JMX already
has a place where it lends a big help, I am resistent to endorsing a path where
it is the *only* solution. As long as we can make it *one* solution out of
many, I will happily shut my trap.
Since you mentioned moving back and forth between JMX enabled and JMX
based is bad, that is yet another red flag that maybe we don't want to
go down that road. But that is my conservative side talking. I'm not
going to get in the way if you hell bent on going that direction. I'm
just trying to find some balance here.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Berin Loritsch <bl...@apache.org>
> Antworten an: geronimo-dev@incubator.apache.org
> Datum: Tue, 12 Aug 2003 11:39:44 -0400
> An: geronimo-dev@incubator.apache.org
> Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>
> Jens Schumann wrote:
>
> The thing is that there are certain compromises in the all-in-one box that
> you have no control over. Usually the manufacturers of these boxes can only
> spend money on one part of it, and they skimp on the rest. So it may have
> a good tape player, but the CD player sucks (or vice versa).
I agree with you. However I still don't get the point why relying on JMX is
a critical factor, and usage of jakarta-commons* is considered harmful. JMX
is a specification and it is up to you to implement it.
>> In the end it all boils down to whether a system is JMX enabled or JMX
>> based. Interestingly most projects I have seen moved to JMX enabled at some
>> stage, since too much stuff was maintained in parallel. However the
>> transition from one to the other model is something you should avoid (just
>> take a look at tomcat 5).
>
> <shudder/>
>
> Seriously though, I would much prefer to have JMX enabled than JMX based,
> as we can have more fine tuned control where we need it. The JMX dynamic
> classloading might be something causing problems instead of solving them.
> If that happens, what is your recourse?
See above, it is a specification. And I don't say JMX based is the only
solution. But I believe most people here on the list talk about the
instrumentation level only.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>MBean != interface, and we should never use them as such. By following that
>>mantra, dynamic MBeans becomes a viable tool with few drawbacks.
>
>
> Well, this is true if you talk about the instrumentation level only. But if
> you trust in JMX agents for application management you are moving towards
> the MBean == interface analogy. In my opinion JMX offers a lot more than
> management, stuff you need to implement anyway: Dynamic Classloading,
> Notifications, Monitoring, Relations and Lifecycle of components.
My alarm bells go off every time I hear that an object should ever be considered
synonymous with a simple interface.
All of those other aspects: dynamic classloading, notifications, monitoring,
etc. can be addressed by other means--many times more effectively.
I get nervous when I here something slices, dices, makes julian fries, and
will not break (oops! it broke). That combination hooka and coffie maker
(get the movie reference now?) might better be served with different mechanisms.
For example, in the world of audio and home entertainment systems, you have
two camps:
1) The all in one jobbies--usually less expensive
2) Component systems--usually more expensive
The thing is that there are certain compromises in the all-in-one box that
you have no control over. Usually the manufacturers of these boxes can only
spend money on one part of it, and they skimp on the rest. So it may have
a good tape player, but the CD player sucks (or vice versa).
With the component systems, you can get exactly what you want for the job
at hand. If you don't want a tape player, you don't have to buy one. If
you really care about your CD player, you can spend money on a good one.
In other words, if something isn't up to snuff you have the ability to swap
it out at any time for a better component. You aren't stuck with what the
initial manufacturer decided was best for you.
> In the end it all boils down to whether a system is JMX enabled or JMX
> based. Interestingly most projects I have seen moved to JMX enabled at some
> stage, since too much stuff was maintained in parallel. However the
> transition from one to the other model is something you should avoid (just
> take a look at tomcat 5).
<shudder/>
Seriously though, I would much prefer to have JMX enabled than JMX based,
as we can have more fine tuned control where we need it. The JMX dynamic
classloading might be something causing problems instead of solving them.
If that happens, what is your recourse?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Berin Loritsch <bl...@apache.org>
>
>
> Consider for a moment the purpose of MBeans. They are to allow a management
> console to control aspects of your software. So they were originally created
> to provide an end user a way to control the guts of software. They were not
> created to provide a direct programmatic interface to the underlying software.
>
> So if you lookup your components and access them by a direct Java interface,
> then you can easily remote that component, control the inheritance structure,
> and still have the benefit of what JMX was designed for.
>
I think it depends on how much of your application is moved to the JMX
model. If you use it as a simple add on (which was the initial intend of
JMX, and it looks like you are moving towards that direction) then I would
agree. But the JMX spec also contains the agent specification, and thus
being said manageable aspects of software can (and in my opinion should) be
much more than providing a simple management interface to application
components.
> MBean != interface, and we should never use them as such. By following that
> mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Well, this is true if you talk about the instrumentation level only. But if
you trust in JMX agents for application management you are moving towards
the MBean == interface analogy. In my opinion JMX offers a lot more than
management, stuff you need to implement anyway: Dynamic Classloading,
Notifications, Monitoring, Relations and Lifecycle of components.
In the end it all boils down to whether a system is JMX enabled or JMX
based. Interestingly most projects I have seen moved to JMX enabled at some
stage, since too much stuff was maintained in parallel. However the
transition from one to the other model is something you should avoid (just
take a look at tomcat 5).
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Berin Loritsch <bl...@apache.org>.
Jens Schumann wrote:
>>Von: Greg Wilkins <gr...@mortbay.com>
>>
>>
>>Why can't we go for a totally dynamic MBean model?
>>
>
>
> Just a few thoughts:
>
> - With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
> introduced) you get meta data for SimpleMBeans.
> - With dynamic Mbeans you loose your concrete interface, and with it a
> simple way to create proxies to them (remote access etc.)
> - Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
> MBeans.
Consider for a moment the purpose of MBeans. They are to allow a management
console to control aspects of your software. So they were originally created
to provide an end user a way to control the guts of software. They were not
created to provide a direct programmatic interface to the underlying software.
So if you lookup your components and access them by a direct Java interface,
then you can easily remote that component, control the inheritance structure,
and still have the benefit of what JMX was designed for.
MBean != interface, and we should never use them as such. By following that
mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Remember, JMX is a tool but a golden hammer it is not.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Jens Schumann <je...@void.fm>.
> Von: Greg Wilkins <gr...@mortbay.com>
>
>
> Why can't we go for a totally dynamic MBean model?
>
Just a few thoughts:
- With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
introduced) you get meta data for SimpleMBeans.
- With dynamic Mbeans you loose your concrete interface, and with it a
simple way to create proxies to them (remote access etc.)
- Don't forget inheritance - in my opinion pretty dangerous by using Dynamic
MBeans.
Jens
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by David Jencks <da...@snappydsl.net>.
Using model mbeans instead of standard mbeans has many advantages. As
I recall someone (Simone?) offered to write an xmbean model mbean for
mx4j. We can use the xdoclet JBoss xmbean template as a starting point
and generate the xml descriptor from the source.
For now we can generate standard mbean interfaces and, when we get an
xmbean impl. switch over with minimal effort. Including appropriate
documentation now will make the switch easier.
Is xdoclet being used in the current build system?
david jencks
On Tuesday, August 12, 2003, at 09:07 AM, Greg Wilkins wrote:
>
>
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>>
>>>
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
>
> Why can't we go for a totally dynamic MBean model?
>
> Ie - for a given FooService, why do we need to write a FooServiceMBean
> interface that just has the methods we wish to expose?
>
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> I think we should be able to just create the FooService objects
> and then describe any MBeans we want for them in XML - describing
> the methods and the meta data in one spot.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
>
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
>
>
> --
> Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
> Mort Bay Consulting Australia and UK. http://www.mortbay.com
>
Re: Dynamic MBeans. Was: Kernel Architecture
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 12, 2003, at 14:07 Europe/London, Greg Wilkins wrote:
> James Strachan wrote:
>
>>>> An interface based MBean is just a naming convention. There is no
>>>> tying to anything. Indeed there's not even a dependency on JMX
>>>> never mind any other container API. Then the container is totally
>>>> free to go in whatever direction it wishes.
>>> But by creating (and calling) them MBeans, you are tying it down to
>>> a naming convention expected by JMX which may confuse the issue
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be
>> any less confusing?
>
> Why can't we go for a totally dynamic MBean model?
Yes, this is precisely the kind of thing I was working towards. In the
code sample posted earlier, I wanted to demonstrate how it could be
done to avoid dependency on the JMX spec of calling things MBean, but
still provide that as a service. There's no reason why it couldn't be
achieved using a dynamic interface instead.
> This is the simplest form of MBean, but contains no meta data to
> describe that MBean - which has to be placed in an xml file elsewhere.
>
> If we decide not to use MBeans, then we still have our FooService
> objects and we have no FooServiceMBean objects clutering up the
> repository.
Yes, the less clutter (and dependency on MBeans) the better.
> If we decide to use MBeans - it means that we will have fewer
> undocumented MBeans without real meta data. We can also expose
> more of an object simply by changing the MBean descriptor file.
Agree completely.
Alex.