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/04/01 21:46:47 UTC
v4 jmx kernel
I've been looking at the kernel, and to be honest, I find it
a lot more complicated than it has to be.
I think that for version 4, Main.class should be rewritten so
that the Kernel is a Component with all the lifecycle methods.
This allows for easier jmx management (since it can simply
be managed through the standard to-be-created default
dynamic MBean).
The class that creates the kernel would look like the file
I've attached (it's non-working yet). Note: I'm not using a
pipeline for creation of the kernel. I'm assuming this is not
neccessary for security, though I'm not sure about that.
thoughts?
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>
Re: v4 jmx kernel
Posted by Federico Barbieri <sc...@betaversion.org>.
Leo Simons wrote:
>
> I've been looking at the kernel, and to be honest, I find it
> a lot more complicated than it has to be.
>
agree.
Anyway if you are interested there is a jmx kinda version of avalon on
eas.betaversion.org (follow direction for the CVS). It's not a jmx
kernel but support JMX blocks. I not sure thou if the JMX RI licence
allow redistribution.
For those who will be at ApacheCon and want to meet here's a beacon,
drop me a call at 408 420 5811. We'll arrange a beer/brainstrom meeting
:]
Fede
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: v4 jmx kernel
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Sunday, 01 April, 2001 21:47
> To: Avalon Development
> Subject: v4 jmx kernel
>
>
> I've been looking at the kernel, and to be honest, I find it
> a lot more complicated than it has to be.
>
> I think that for version 4, Main.class should be rewritten so
> that the Kernel is a Component with all the lifecycle methods.
+1
> This allows for easier jmx management (since it can simply
> be managed through the standard to-be-created default
> dynamic MBean).
..and easier remote management using CORBA. If the Kernel is a Component
I can easily wrap this and handle romote invocation of management controls
and notification by the Kernel to a remote manager (or delegated audit
server) of Kernel state changes.
Cheers, Steve.
> The class that creates the kernel would look like the file
> I've attached (it's non-working yet). Note: I'm not using a
> pipeline for creation of the kernel. I'm assuming this is not
> neccessary for security, though I'm not sure about that.
>
> thoughts?
>
> 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: v4 jmx kernel
Posted by Peter Donald <do...@apache.org>.
Sidenote: New Avalon contributtors should update docs to indicate that they
are contributors ;)
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: v4 jmx kernel
Posted by Peter Donald <do...@apache.org>.
At 08:54 2/4/01 +0200, Leo Simons wrote:
>After reading the white paper (which sounds pretty good
>except for the requirment that the Log Manager should
>handle internationalisation issues), I'm wondering what
>the plans are for Avalon in the long run.
>It seems to me that Avalon itself would become mostly
>redundant somewhere in the future, phoenix would become
>a JSF implementation, and cornerstone would provide
>some default JSF Services, should we choose to adapt
>to JSF.
We have actually been contacted already by HP (the proposers) and some of
the members of JCP EC (people who decide whether it is accepted or not). So
if it gets accepted then it seems likely that the RI will be built at
apache. The next major revision of phoenix will then likely be JSF compatible.
If/when/how it happens has not really been decided but even if it did then
I don't think it would invalidate the avalon framework part. I use the
framework part in a lot of other non-server related environments (mainly
graphics/geometry processing CLI apps) and still think it is great for what
it does.
>What are the thoughts on this? Should we start preparing
>for this change?
yes/no/maybe ;)
Until it is accepted then we shouldn't do anything (I think it was
scheduled for vote on 3rd). After it is voted then hopefully anyone
interested should apply to be a member of expert group. Given that the
development duration of such a JSR I think it will be a while before
anything concrete comes out - until such a time I will be continuing dev on
phoenix/cornerstone because I need the facilities today ;)
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: v4 jmx kernel
Posted by Leo Simons <ma...@leosimons.com>.
> >> I think we need to formally define a new object to make things
> easier. The
> >> Services JSR calls this object the "Embeddor" (sp?).
> >
> >Where do I find that?
>
>
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_111_jsf.html
just read the white paper...
> >> Essentially it is
> >> responsible for
> >> * creating MBeanServer
> >> * starting MBeanServer
> >> * creating kernel
> >> * starting kernel
> >>
> >> and optionally for
> >> * creating deployer
> >> * using deployer to deploy from default location(s)
> >> * creating default logEngine
> >> * setting up default log for kernel
> >> * loading kernel services (aka facilities)
from the white paper:
The JSF is designed to be embedded within a larger context. For example, an
implementation of the JSF could be embedded within a database, an
application server, or a router. For this reason, an embeddor is needed to
communicate with the external environment and provide the information it
obtains to the services that it hosts.
At a functional level, the role of the embeddor within the framework is to:
1. Create an instance of a kernel.
2. Initialize the kernel.
3. Start the kernel.
4. Stop the kernel.
5. Destroy the kernel.
An embeddor can monitor the life cycle of the kernel using functionality
that is built into the kernel.
(...)
The Role of Embeddors
Embeddors are the shells that create a server environment within a device.
Any embeddable device that can support a JVM can contain an embeddor. The
embeddor interacts with both the physical device and the application that it
contains. It extracts information from the physical environment and
communicates it to the applications on an as needed basis. It is also
capable of performing the same role within diverse software environments.
At the system level, an embeddor is an object. It maintains a peer
relationship with the process or application that is the externally visible
server. The embeddor can be as simple as a wrapper that exposes the
functionality of the internal components or as complex as a database server
within which a server is embedded.
Because embeddors must interact with the device on which they reside, they
must be customized to conform to that physical environment. In addition,
embeddors that are used with the JSF must provide the following basic
functionality:
? Provide an interface between the kernel and the external environment.
? Provide the kernel with the configuration URL.
? Provide the means to create instances of the kernel.
(...)
The Kernels Core Management Facilities
The JSF kernel provides fundamental functionality to the other framework
components. Each type of component receives a different set of capabilities
from the kernel. The kernel exposes several disparate interfaces to limit
the capabilities that are exposed to each component type.
The kernel is responsible for creating and maintaining the following
framework elements:
? The JMX MBean Server
? The JNDI Registry
? The Service Manager
? The Configuration Manager
? The Log Manager
? The Deployment Manager
? The Security Manager
(...)
If we want to follow this model, the Embeddor should not be
responsible for MBeanServer, Deployer, etc.
After reading the white paper (which sounds pretty good
except for the requirment that the Log Manager should
handle internationalisation issues), I'm wondering what
the plans are for Avalon in the long run.
It seems to me that Avalon itself would become mostly
redundant somewhere in the future, phoenix would become
a JSF implementation, and cornerstone would provide
some default JSF Services, should we choose to adapt
to JSF.
What are the thoughts on this? Should we start preparing
for this change?
(it would, among other things, require some significant
changes to the lifecycle stages:
"
1 Resolution
2 Initialization
3 Start
4 Reconfiguration
5 Stop
6 Destruction
The following sections describe each of these phases.
Phase 1: Resolution
During the service resolution phase, the following activities occur:
1 The services manager (ServiceManager) is instantiated.
2 The services class loader is created.
3 The services service context is created.
4 The packages that can be provided by the service are exported to the
kernel.
5 All configured children are taken through their resolution phase.
Phase 2: Initialization
During the service initialization phase, the following activities occur:
1 A check is made to ensure that the kernel can provide all required
packages.
2 The service implementation is instantiated.
3 The service is registered with the service registry.
4 The service is provided with its service context
5 The service is asked to initialize itself (if it has implemented the
Initializable interface).
6 All of the services children are initialized.
7 Monitoring of the services configuration URL is initiated.
Phase 3: Start
During the service start phase, the following activities occur:
1 Logical references to dependent services are resolved.
2 The service is asked to start itself. During this request a service may
acquire references to its dependent services.
3 All of the services children are started.
Phase 4: Reconfiguration
During the service reconfiguration phase, the following activities occur:
1 The services reconfigureService() method is invoked.
2 The service uses the configuration manager provided through the service
context to retrieve a configuration object.
3 The configuration object is used to obtain the configuration information.
4 The service applies the new configuration information to itself.
Phase 5: Stop
During the service stop phase, the following activities occur:
1 The service is asked to stop itself.
2 All of the services children are stopped.
3 All dependent services acquired by the service are released.
Phase 6: Destruction
During the service destruction phase, the following activities occur:
1 If the service is running, it is stopped.
2 All of the services children are stopped.
3 All dependent services acquired by the service are released.")
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: v4 jmx kernel
Posted by Peter Donald <do...@apache.org>.
At 07:56 2/4/01 +0200, Leo Simons wrote:
>> Well for one you didn't follow the code conventions ;)
>
>I thought there had been an okay-if-you-really-want-to vote on this?
nope ;)
>> I think we need to formally define a new object to make things easier. The
>> Services JSR calls this object the "Embeddor" (sp?).
>
>Where do I find that?
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_111_jsf.html
>> Essentially it is
>> responsible for
>> * creating MBeanServer
>> * starting MBeanServer
>> * creating kernel
>> * starting kernel
>>
>> and optionally for
>> * creating deployer
>> * using deployer to deploy from default location(s)
>> * creating default logEngine
>> * setting up default log for kernel
>> * loading kernel services (aka facilities)
>
>Sounds good. Want to write one? =)
okay ;)
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: v4 jmx kernel
Posted by Leo Simons <ma...@leosimons.com>.
> Well for one you didn't follow the code conventions ;)
I thought there had been an okay-if-you-really-want-to vote on this?
> but other than that
> the following
>
> kernel.loadServices();
> kernel.installServices();
> kernel.runServices();
> kernel.loadServerApplications();
> kernel.installServerApplications();
> kernel.runServerApplications();
>
> IMHO it should be up to a Deployer (or Installer) to load/install services
> and applications. This allows different types of installers/deployers to
> install different types of applications (Something I need for my own
> projects).
Yep. My idea was that the kernel was loaded like this because the kernel
should set up the deployer based on configuration info, and it is kind-of
a waste to create a deployer for just the kernel.
> I think we need to formally define a new object to make things easier. The
> Services JSR calls this object the "Embeddor" (sp?).
Where do I find that?
> Essentially it is
> responsible for
> * creating MBeanServer
> * starting MBeanServer
> * creating kernel
> * starting kernel
>
> and optionally for
> * creating deployer
> * using deployer to deploy from default location(s)
> * creating default logEngine
> * setting up default log for kernel
> * loading kernel services (aka facilities)
Sounds good. Want to write one? =)
cheers!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: v4 jmx kernel
Posted by Peter Donald <do...@apache.org>.
At 09:46 1/4/01 +0200, Leo Simons wrote:
>I've been looking at the kernel, and to be honest, I find it
>a lot more complicated than it has to be.
It is complicated and a bit messy - but that is more because it evolved out
of 3 different codebases rather than being rewritten from scratch.
>I think that for version 4, Main.class should be rewritten so
>that the Kernel is a Component with all the lifecycle methods.
It is ;) (Follow inheritance hierarhy for ServerKernel interface)
>This allows for easier jmx management (since it can simply
>be managed through the standard to-be-created default
>dynamic MBean).
right.
>The class that creates the kernel would look like the file
>I've attached (it's non-working yet). Note: I'm not using a
>pipeline for creation of the kernel. I'm assuming this is not
>neccessary for security, though I'm not sure about that.
>
>thoughts?
Well for one you didn't follow the code conventions ;) but other than that
the following
kernel.loadServices();
kernel.installServices();
kernel.runServices();
kernel.loadServerApplications();
kernel.installServerApplications();
kernel.runServerApplications();
IMHO it should be up to a Deployer (or Installer) to load/install services
and applications. This allows different types of installers/deployers to
install different types of applications (Something I need for my own
projects).
I think we need to formally define a new object to make things easier. The
Services JSR calls this object the "Embeddor" (sp?). Essentially it is
responsible for
* creating MBeanServer
* starting MBeanServer
* creating kernel
* starting kernel
and optionally for
* creating deployer
* using deployer to deploy from default location(s)
* creating default logEngine
* setting up default log for kernel
* loading kernel services (aka facilities)
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