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