You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/01 07:20:25 UTC
RE: jmx
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
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