You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/03/31 21:36:28 UTC
RE: jmx
> I don't have the parts, but it is easy to write one.
> DynamicMBean basically has
> - get|set Attributes: Java Beans reflection would map to actual service
> - invoke: again reflection to rescue.
> It sould be easy to point to a class or interface and wrap it
> dynamically by
> a DynamicMBean wrapper. This wrapper could be influnced by configuration
> files and driven by JMX agents. This would not do full JMX compliance but
> would get the first stage and then more complex parts of the Spec could be
> tackled.
I get the idea. It was sort of what I was thinking -> another option
instead of DynamicMBeans is the use of Model MBeans, which probably
means some of the reflection work is not neccessary. These are not
implemented by enhydra jmx, though.
> Let me know if you want some help.
Definately!
> I have been thinking of JMX and Avalon.
> Just didn't get the time. Would be happy to help out.
I'm at the moment looking into the available code (downloaded 70megs of
Enhydra Enterprise so far =) and documentation, to familiarise myself
with jmx.
After that, I will evaluate the different options (which jmx agent impl.
to start with, which kernel loading model to adapt (jboss vs enhydra vs
tomcat), and then the best way to wrap the various avalon services in
MBeans.
Once that's up and running, I'll look at writing an adapter / html-based
admin interface like provided by the RI. I might even try learning some
GUI programming to build a graphical tool =)
So, the process to follow as I envision it would be:
1 - get Enhydra running, compare jmx impl to reference impl
2 - if we choose Enhydra, extract jmx code from it
3 - look into license issues (I don't expect difficulties)
4 - redesign kernel to prepare for jmx (especially Main.class, probably)
5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
implement Phoenix's services as MBeans.
6 - write custom adapter (avalon-based using RMI, probably)
7 - write management app to talk to adapter (either java program or
servlet-based)
long-term:
8 - create our own jmx impl
9 - design authentication scheme for allowing access to adapter
I'd like any and all suggestions for #4-7, as well as help actually
implementing all this stuff. Harmeet, I'm guessing you'd be most
productive helping out with the kernel design. So draw up some
schematics, if you want ;-)
Oh, comments on the route to follow welcome as well =)
g'night, all!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
Just a note about JMX stuff - I guess the most important thing is just to
get it done. We can refactor it and pretty it up later. So if anything
seems like too much work to do the "proper way" and we can can hack it
together now then do it. We can refactor later.
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> > So, the process to follow as I envision it would be:
(...)
Harmeet:
> I think it would be useful finisih things in layers.
> Layers could be
> a) Get the reconfiguration working via JMX interfaces.
> b) Get Notification interfaces working. This is really important,
> beacause a
> server framework needs to tell the right people about the state.
> c) do integration of JMX with SNMP, WBEM etc. Whatever the adminstrators
> need to manage the server.
> d) Get the class reloading , kernel design issues right.
>
> I think (a), (b), (c) are really important and in some way add to but not
> require dramatic changes to the Avalon Kernel. (d) would require maximum
> changes, but I think a good server solution would have redundancy, so it
> should be ok to provide a good stable server solution without even doing
> (d). On the other hand (d) seems interesting.
> I don't know much of the kernel, the changes I did in earlier Avalon
> framework were pre-phoenix.
>From the fact that phoenix is not present in 4.0 yet, I figured it is to
undergo a bit of a redesign. Thus, this is the right time to get jmx into
it - things should get stable at v4. Therefore, it seems like a good idea
to start with (d)...and it's more fun this way too =)
> My impression has been that Enhydra provides a lot of things - Reloading,
> SNMP, JNDI namespace, logging etc. It is and Avalon competitor.
Hmm. Enhydra 3.1 is a competitor for OpenEJB etc. 4.0 for other J2EE
implementations. Avalon does not try to be a J2EE implementation - I
feel it is both below and beyond that spec.
Thus, they're not in the same problem space and therefore not direct
competitors. But it is true there is quite a bit overlap =)
> I
> had tried
> to the some of the above things, like running Enhydra, trying to
> make sense
> out of their JMX stuff etc,
Me too. I've decided it would take less time to think this up ourselves
than to borrow ideas from Enhydra =) ... but it might be good for the
project if you disagree with me...
greetz,
LSD, who hasn't got too much time for Avalon this week, so hopes you
accept delays in responses from him as well
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: jmx
Posted by Harmeet Bedi <hb...@yahoo.com>.
> So, the process to follow as I envision it would be:
>
> 1 - get Enhydra running, compare jmx impl to reference impl
> 2 - if we choose Enhydra, extract jmx code from it
> 3 - look into license issues (I don't expect difficulties)
> 4 - redesign kernel to prepare for jmx (especially Main.class, probably)
> 5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
> implement Phoenix's services as MBeans.
> 6 - write custom adapter (avalon-based using RMI, probably)
> 7 - write management app to talk to adapter (either java program or
> servlet-based)
> long-term:
> 8 - create our own jmx impl
> 9 - design authentication scheme for allowing access to adapter
I think it would be useful finisih things in layers.
Layers could be
a) Get the reconfiguration working via JMX interfaces.
b) Get Notification interfaces working. This is really important, beacause a
server framework needs to tell the right people about the state.
c) do integration of JMX with SNMP, WBEM etc. Whatever the adminstrators
need to manage the server.
d) Get the class reloading , kernel design issues right.
I think (a), (b), (c) are really important and in some way add to but not
require dramatic changes to the Avalon Kernel. (d) would require maximum
changes, but I think a good server solution would have redundancy, so it
should be ok to provide a good stable server solution without even doing
(d). On the other hand (d) seems interesting.
I don't know much of the kernel, the changes I did in earlier Avalon
framework were pre-phoenix.
My impression has been that Enhydra provides a lot of things - Reloading,
SNMP, JNDI namespace, logging etc. It is and Avalon competitor. I had tried
to the some of the above things, like running Enhydra, trying to make sense
out of their JMX stuff etc, but could not get enough cycles in it. At one
point I found some documentaion on how they do class reloading. Apparently
they have a hierarchy of class loaders, and a delegated class reloading
mechanism. Will try to look it up.
Sorry about the delay in response, got sucked into something and poof goes
the weekend. :-(
Harmeet
>
> I'd like any and all suggestions for #4-7, as well as help actually
> implementing all this stuff. Harmeet, I'm guessing you'd be most
> productive helping out with the kernel design. So draw up some
> schematics, if you want ;-)
> Oh, comments on the route to follow welcome as well =)
>
> g'night, all!
>
> LSD
>
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> LSD.URL( [
> http://www.leosimons.com, // personal website
> http://www.atfantasy.com, // fantasy RPG portal
> http://www.the-sign.nl // web-design company
> ] );
> LSD.quote("Buh!");
> email.setSig((String)LSD);
> </java:sig>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
At 07:56 2/4/01 +0200, Leo Simons wrote:
>> >I'm using org.apache.jmx right now for simple wrappers around sun's
>> >RI, allowing for easy swapping of implementations. Can someone set
>> >up the repository so I can commit this?
>>
>> Not sure what you mean? Do you want to add it in a new repository or can
>> you just keep it in phoenix's repository for the moment?
>
>I guess it should be in phoenix's until it actually gets written,
>which would probably warrant a new jakarta sub-project. But I'm
>not sure whether I can create org.apache.jmx in the phoenix
>repository (still brand-new to CVS ;/
just "cvs add my/dir/name/here" ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> >I'm using org.apache.jmx right now for simple wrappers around sun's
> >RI, allowing for easy swapping of implementations. Can someone set
> >up the repository so I can commit this?
>
> Not sure what you mean? Do you want to add it in a new repository or can
> you just keep it in phoenix's repository for the moment?
I guess it should be in phoenix's until it actually gets written,
which would probably warrant a new jakarta sub-project. But I'm
not sure whether I can create org.apache.jmx in the phoenix
repository (still brand-new to CVS ;/
greetz,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
At 09:46 1/4/01 +0200, Leo Simons wrote:
>> 1 - get Enhydra running, compare jmx impl to reference impl
>
>Enhydra lacks support for some jmx features. I've decided to
>use the RI for development.
kewl.
>> 3 - look into license issues (I don't expect difficulties)
>
>there are none. Both enhydra (in source form or any other way)
>and the RI (though we can only distribute in in binary form)
>can be easily used with the apache license.
It is fine to use the binary version but in the long run we will have to
find/implement our own or else suns lawyers won't allows us to describe
Avalon as JMX enabled (legally).
>> 5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
>> implement Phoenix's services as MBeans.
>
>I think dynamic MBeans are the best idea. I want to create a default
>dynamic MBeanInfo that calls all of the avalon lifecycle methods.
>This should be located in org.apache.phoenix.engine.jmx.
excellent - me too ;)
>> 6 - write custom adapter (avalon-based using RMI, probably)
>
>there are a few pointers on an RMI adapter in the spec. It is likely
>that a feature version will hammer this out further. So an RMI adapter
>is probably the way to go.
sounds good.
>> 8 - create our own jmx impl
>
>I'm using org.apache.jmx right now for simple wrappers around sun's
>RI, allowing for easy swapping of implementations. Can someone set
>up the repository so I can commit this?
Not sure what you mean? Do you want to add it in a new repository or can
you just keep it in phoenix's repository for the moment?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> 1 - get Enhydra running, compare jmx impl to reference impl
Enhydra lacks support for some jmx features. I've decided to
use the RI for development.
> 3 - look into license issues (I don't expect difficulties)
there are none. Both enhydra (in source form or any other way)
and the RI (though we can only distribute in in binary form)
can be easily used with the apache license.
> 4 - redesign kernel to prepare for jmx (especially Main.class, probably)
see my other e-mail.
> 5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
> implement Phoenix's services as MBeans.
I think dynamic MBeans are the best idea. I want to create a default
dynamic MBeanInfo that calls all of the avalon lifecycle methods.
This should be located in org.apache.phoenix.engine.jmx.
> 6 - write custom adapter (avalon-based using RMI, probably)
there are a few pointers on an RMI adapter in the spec. It is likely
that a feature version will hammer this out further. So an RMI adapter
is probably the way to go.
> 8 - create our own jmx impl
I'm using org.apache.jmx right now for simple wrappers around sun's
RI, allowing for easy swapping of implementations. Can someone set
up the repository so I can commit this?
greetz,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> >> So the actual "doing" part is done in user land and it is only the glue
> >> that exists in the kernel. When no .sar is loaded to provide
> service then
> >> default implementations of Facilities are used.
> >
> >Hmm. An MBean is allowed to get a reference to the MBeanServer by
> >implementing
> >some specific interface. It might make more sense to just
> request a Facility
> >from the MBeanServer; this allows for more generic MBeans. This needs a
> >little
> >more thinking, I think.
Actually, when we keep the "lightweight" idea in mind, none of the jmx
stuff should be needed so this is not a good idea. But, if phoenix should
run on a really tight memory space, it might make sense to not even have
the default implementations directly and put them all in special
"facility .sars".
> >> I was hoping that the impact of JMX on the system would be
> >> minimal - how do
> >> you see it? I assume there will need to be entries in config files that
> >> mark particular apps/blocks as manageable but is there a need to pu JMX
> >> specific information in the config file ?
> >
> >I'm not entirely sure yet. If we really use DynamicMBeans for everything,
> >no. If we also use standard MBeans, or want to provide the option, it is
> >definately the most logical thing to do. But I'm not sure whether it is
> >really neccessary...
>
> sounds good.
>
> >> Would it be possible for the services not to extend DynamicMBean but
> >> instead a wrapper be used ?
> >
> >Sure thing. But why?
>
> The less dependencies the better. One of my long-term goals is to get
> Phoenix running on consoles like Playstation2 - thats a while off yet ;)
> But I would prefer to keep everything as lightweight as possible - and if
> it doesn't *need* to be a dependency then ... ;)
got it. JMX should be a plug-in module loaded from a .sar or some related
mechanism so it can easily be removed from the system. The one class to
change then would be Main.class (or the to-be-created Embeddor, perhaps),
which needs to toggle loading of JMX through some command-line option.
I was thinking perhaps switching to jmx for loading of Facilities etc, but
this is definately not leightweight (as that implies a jmx adapter and other
'heavy' stuff).
We're going for added complexity to add functionality once more =)
thought: perhaps it is not a good idea to have one kernel do everything.
Maybe there should be an enterprise-oriented phoenix, a user-oriented
phoenix, and a leightweight phoenix (like they've done for the java
platform. Well?
greetz,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
At 07:56 2/4/01 +0200, Leo Simons wrote:
>> Okay - I am not sure how to do it exactly but lets just something like the
>> following happens. A ServerApplication starts up, somehow it is marked as
>> wanting to access/provide a kernel Facility. (Facilitys being the name I
>> chose for kernel level services). It receives a reference to an interface
>> that it can use to provide this Facility. It then interfaces to
>> kernel (and
>> thus other ServerApplications) through this interface.
>>
>> So the actual "doing" part is done in user land and it is only the glue
>> that exists in the kernel. When no .sar is loaded to provide service then
>> default implementations of Facilities are used.
>
>Hmm. An MBean is allowed to get a reference to the MBeanServer by
>implementing
>some specific interface. It might make more sense to just request a Facility
>from the MBeanServer; this allows for more generic MBeans. This needs a
>little
>more thinking, I think.
;)
>> I was hoping that the impact of JMX on the system would be
>> minimal - how do
>> you see it? I assume there will need to be entries in config files that
>> mark particular apps/blocks as manageable but is there a need to pu JMX
>> specific information in the config file ?
>
>I'm not entirely sure yet. If we really use DynamicMBeans for everything,
>no. If we also use standard MBeans, or want to provide the option, it is
>definately the most logical thing to do. But I'm not sure whether it is
>really neccessary...
sounds good.
>> Would it be possible for the services not to extend DynamicMBean but
>> instead a wrapper be used ?
>
>Sure thing. But why?
The less dependencies the better. One of my long-term goals is to get
Phoenix running on consoles like Playstation2 - thats a while off yet ;)
But I would prefer to keep everything as lightweight as possible - and if
it doesn't *need* to be a dependency then ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> Okay - I am not sure how to do it exactly but lets just something like the
> following happens. A ServerApplication starts up, somehow it is marked as
> wanting to access/provide a kernel Facility. (Facilitys being the name I
> chose for kernel level services). It receives a reference to an interface
> that it can use to provide this Facility. It then interfaces to
> kernel (and
> thus other ServerApplications) through this interface.
>
> So the actual "doing" part is done in user land and it is only the glue
> that exists in the kernel. When no .sar is loaded to provide service then
> default implementations of Facilities are used.
Hmm. An MBean is allowed to get a reference to the MBeanServer by
implementing
some specific interface. It might make more sense to just request a Facility
from the MBeanServer; this allows for more generic MBeans. This needs a
little
more thinking, I think.
>
> >> In terms of Phoenix I would love to see the
> agent/distributor/entry-point
> >Can't follow you here - the number of management apps does not depend on
> >the kernel but on the MBeanServer, which supports multiple by default.
>
> Right - well think of another Facility - naming/logging/whatever. The
> provider should decide how the Facility is provided rather than
> anything in
> the kernel is what I was trying to get across.
Ah. Sounds logical. Can't immediately think of how to write code for this,
though (lack of examples =).
> >Loading of user .sars is left for the Kernel itself to handle. It should
> >take care of discovering and registering all MBeans in those
> applications,
> >probably by looking at mlet tags in the server.xml file (m-lets are not
> >supported by the enhydra jmx impl though).
>
> I was hoping that the impact of JMX on the system would be
> minimal - how do
> you see it? I assume there will need to be entries in config files that
> mark particular apps/blocks as manageable but is there a need to pu JMX
> specific information in the config file ?
I'm not entirely sure yet. If we really use DynamicMBeans for everything,
no. If we also use standard MBeans, or want to provide the option, it is
definately the most logical thing to do. But I'm not sure whether it is
really neccessary...
> >The Kernel services to be separated out...
> >----------
> >- jndi?
>
> If jndi == naming then +1 ;)
what I ment =)
> I am not sure why the following 2 are included???
> >- storage service
> >- timer/scheduling service
Just listed them because they're both things you'd expect
to find in a kernel. I'm not quite sure at what sys-level
phoenix should be (i.e. should another kernel be built on
top of it if you want higher-level-facilities like this?).
> Would it be possible for the services not to extend DynamicMBean but
> instead a wrapper be used ?
Sure thing. But why?
gotta go!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
At 01:30 1/4/01 +0200, Leo Simons wrote:
>> one thing I would like to see is that is that some of this is implemented
>> in user-space (ie as a .sar). The closest thing I guess is the way syslog
>> works under many unixes. In many cases there is a kernel module that
>> redirects kernel logging (and sometimes logging originating in libc) to a
>> file and/or user-level process. The user level process (ie syslogd) would
>> then do with it as it wills.
>
>Not sure I get this...do you mean the Kernel should have a
>
>setLoggerDestination(Logger newLogger)
>
>which is called from a .sar?
>I myself was thinking we'd have a sys/ directory, which doesn't contain the
>actual apps, but rather .sar files providing the kernel-level services. We'd
>have to shield the user apps from some of the access the kernel-level
>services should have.
Okay - I am not sure how to do it exactly but lets just something like the
following happens. A ServerApplication starts up, somehow it is marked as
wanting to access/provide a kernel Facility. (Facilitys being the name I
chose for kernel level services). It receives a reference to an interface
that it can use to provide this Facility. It then interfaces to kernel (and
thus other ServerApplications) through this interface.
So the actual "doing" part is done in user land and it is only the glue
that exists in the kernel. When no .sar is loaded to provide service then
default implementations of Facilities are used.
>> In terms of Phoenix I would love to see the agent/distributor/entry-point
>?
>> as a sar but the core access-points provided by the kernel somehow. That
>> way we could theoretically have multiple management apps or none at all or
>> any other combination ;) Thoughts?
>
>Can't follow you here - the number of management apps does not depend on
>the kernel but on the MBeanServer, which supports multiple by default.
Right - well think of another Facility - naming/logging/whatever. The
provider should decide how the Facility is provided rather than anything in
the kernel is what I was trying to get across.
>Loading of user .sars is left for the Kernel itself to handle. It should
>take care of discovering and registering all MBeans in those applications,
>probably by looking at mlet tags in the server.xml file (m-lets are not
>supported by the enhydra jmx impl though).
I was hoping that the impact of JMX on the system would be minimal - how do
you see it? I assume there will need to be entries in config files that
mark particular apps/blocks as manageable but is there a need to pu JMX
specific information in the config file ?
>The Kernel services to be separated out...
>----------
>- management (jmx) service
>- logging service (LogKit)
>- deployer service (Camelot)
>- configuration service
>- security service
>- application runner service (phoenix)
>- classloader service
>- jndi?
If jndi == naming then +1 ;)
I am not sure why the following 2 are included???
>- storage service
>- timer/scheduling service
>How the kernel services should look like...
>----------
>abstract class KernelService implements DynamicMBean,MBeanRegistration {
Would it be possible for the services not to extend DynamicMBean but
instead a wrapper be used ?
>note:I feel that an apache jmx implementation will be tremendously
>useful outside of avalon as well, so it should be at org.apache.jmx.
>Agreed?
Sounds good.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Leo Simons <ma...@leosimons.com>.
> one thing I would like to see is that is that some of this is implemented
> in user-space (ie as a .sar). The closest thing I guess is the way syslog
> works under many unixes. In many cases there is a kernel module that
> redirects kernel logging (and sometimes logging originating in libc) to a
> file and/or user-level process. The user level process (ie syslogd) would
> then do with it as it wills.
Not sure I get this...do you mean the Kernel should have a
setLoggerDestination(Logger newLogger)
which is called from a .sar?
I myself was thinking we'd have a sys/ directory, which doesn't contain the
actual apps, but rather .sar files providing the kernel-level services. We'd
have to shield the user apps from some of the access the kernel-level
services should have.
One way to do this would be to have both a StandardKernel and a SystemKernel
interface which are both implemented by the Kernel, and then cast the Kernel
to StandardKernel when a user app wants access, and a SystemKernel when one
of the kernel-level services wants access....
getKernel(ServerApplication sa) {
if(sa instanceof UserApplication)
{
return (StandardKernel)Kernel;
} else {
return (SystemKernel)Kernel;
}
}
only something prettier than that...
> In terms of Phoenix I would love to see the agent/distributor/entry-point
?
> as a sar but the core access-points provided by the kernel somehow. That
> way we could theoretically have multiple management apps or none at all or
> any other combination ;) Thoughts?
Can't follow you here - the number of management apps does not depend on
the kernel but on the MBeanServer, which supports multiple by default.
Here's what I was thinking:
org.apache.phoenix.Startup creates org.apache.jmx.server.MBeanServer,
and then parses commandline info and configuration files. Then, all
.sar files found in the sys/ directory are extracted, and all Service s
exposed that extend SystemService are loaded using jmx.
Then, the Kernel is created. We feed it
org.apache.phoenix.KernelConfiguration
pointing to all the required modules which have just been loaded from sys/,
as
well as to the MBeanServer.
Loading of user .sars is left for the Kernel itself to handle. It should
take care of discovering and registering all MBeans in those applications,
probably by looking at mlet tags in the server.xml file (m-lets are not
supported by the enhydra jmx impl though).
The Kernel services to be separated out...
----------
- management (jmx) service
- logging service (LogKit)
- deployer service (Camelot)
- configuration service
- security service
- storage service
- timer/scheduling service
- application runner service (phoenix)
- classloader service
- jndi?
How the kernel services should look like...
----------
abstract class KernelService implements DynamicMBean,MBeanRegistration {
//std_lifecycle_methods(); should there be install() and uninstall() here?
contextualize(Context context);
compose(ComponentManager componentManager);
configure(Configuration configuration);
init();
start();
run();
suspend();
reconfigure(Configuration configuration);
recontextualize(Context context);
recompose(ComponentManager componentManager);
resume();
stop();
dispose();
finalize();
setLogger(Logger logger);
// directly accessible for easier MBean implementation
void setKernel(Kernel kernel);
Kernel getKernel();
Context getContext();
Configuration getConfiguration();
// ... what else?
// DynamicMBean methods
MBeanInfo getMBeanInfo();
Object getAttribute(String attribute);
AttributeList getAttributes(String[] attributes);
void setAttribute(Attribute attribute);
void setAttributes(AttributeList attributes);
Object invoke(String actionName, Object[] params, String[] signature);
// MBeanRegistration
ObjectName preRegister(MBeanServer server, ObjectName name);
void postRegister(Boolean registrationDone);
void preDeregister();
void postDeregister();
}
they could probably all return an MBeanInfo that is
extended from a default MBeanInfo.
How the source could be restructured....
----------
I feel there should be org.apache.phoenix.services, which
provides all core services. These might implement interfaces
from org.apache.framework or something. Thoughts?
note:I feel that an apache jmx implementation will be tremendously
useful outside of avalon as well, so it should be at org.apache.jmx.
Agreed?
cheers,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jmx
Posted by Peter Donald <do...@apache.org>.
At 09:36 31/3/01 +0200, Leo Simons wrote:
>So, the process to follow as I envision it would be:
>
>1 - get Enhydra running, compare jmx impl to reference impl
>2 - if we choose Enhydra, extract jmx code from it
>3 - look into license issues (I don't expect difficulties)
enhydra is MPLed which is fine for us to use.
>4 - redesign kernel to prepare for jmx (especially Main.class, probably)
>5 - use dynamic MBeans/model MBeans/std mbeans/custom solution to
> implement Phoenix's services as MBeans.
>6 - write custom adapter (avalon-based using RMI, probably)
>7 - write management app to talk to adapter (either java program or
>servlet-based)
excellent!
/me does my best impression of Mr Burns
>long-term:
>8 - create our own jmx impl
egads ! you are keen ;)
>9 - design authentication scheme for allowing access to adapter
>
>I'd like any and all suggestions for #4-7, as well as help actually
>implementing all this stuff.
If you want help cleaning/understanding the kernel then I am your man ;)
>Harmeet, I'm guessing you'd be most
>productive helping out with the kernel design. So draw up some
>schematics, if you want ;-)
one thing I would like to see is that is that some of this is implemented
in user-space (ie as a .sar). The closest thing I guess is the way syslog
works under many unixes. In many cases there is a kernel module that
redirects kernel logging (and sometimes logging originating in libc) to a
file and/or user-level process. The user level process (ie syslogd) would
then do with it as it wills.
In terms of Phoenix I would love to see the agent/distributor/entry-point
as a sar but the core access-points provided by the kernel somehow. That
way we could theoretically have multiple management apps or none at all or
any other combination ;) Thoughts?
>Oh, comments on the route to follow welcome as well =)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org