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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
