avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: jmx
Date Sun, 01 Apr 2001 11:30:46 GMT
> 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


Mime
View raw message