At 09:42 29/3/01 +0200, Leo Simons wrote:
>> I was actually thinking about doing that for cocoon but have been
>> too lazy.
>> It could be good to do if someone was willing to do the work ... ;)
>
>not me, not me! :)
>
>I'm 70% through the JMX spec. This sounds like a very interesting
>project to tackle. I think I'm going to give it a try; coding to
>start somewhere next week.
excellent!
>So, what are the ideas on it so far? Specifically:
>
>- would there be any (license) problems using the RI (the com.sun.*
>classes)?
The license problem would be that we would not be allowed to say that
Avalon/Phoenix was JMX compliant. There are other implementations out there
(enhydra has one) which if switched to later we could now say was jmx
compliant (I think - thou we may need to check with lawyers).
>- has anyone thought about how phoenix/jmx should be integrated (I
> myself see the possibility of simply making the jmx server a
> component, but that may lead to loop dependencies)?
Heres what was discussed a while ago (thou you would have to figure out if
it is the write way to do it).
* Main.class initially starts a MBeanServer.
* Then Main.class would then also send a "go" signal to the MBeanServer
which would launch the kernel and start it up. It could also (optionally?)
install/deploy any .sars in apps directory.
* The Kernel has it's own separate MBean that manages deployment of sars,
and lifecycle of kernel etc. (ie start, stop)
* Each server-application has it's own MBean that is used to manage it's
lifecycle (ie install, deploy, start, stop, undeploy, uninstall). It may
also have a MBean to configure various services
(logging/classpath/policy/configuration/whatever).
* each Block can optionally export a management interface
The way we thought about implementing it was something like
org.apache.phoenix.engine.management.*
Contains generic management classes. ie It would contain default interfaces
(and implementations) for the common lifecycle management interfaces. It
would also contain classes that discover and use dynamic dispatching (via
reflection) of methods/classes etc.
org.apache.phoenix.engine.management.jmx.*
Contains all the management filese directly related to JMX. ie The server
and MBean wrappers. It would most likely use DynamicMBeans (or whatever
they are called) to do the work. It would use
org.apache.phoenix.engine.management.* to do the dispatching etc.
Of course this is long-term ideas and it would be best to start with
something simpler and working ;) What do you think of the above?
>- has anyone thought about how Avalon's Service relates to an MBean?
> (should Service extend MBean?)
Some services are directly equivelent to one of their MBean services are.
ie
org.apache.cornerstone.demos.helloworldserver.HelloWorldServer
Others are more developer orientated rather than management orientated. So
I believe that when we are implementing it we are going to need add an
extra tag to service element in .xinfo files. (Namely to indicate whether
it is a management interface or not). Or maybe we could add extra elements
in .xinfo. I really don't know - I guess it is something you will have to
figure out ;)
>- does anyone know of open source use of jmx besides jboss, enhydra and
> the reference implementation?
nope - theres a few servers that offer a MBean (ie tomcat) but no others I
know of that that use an agent or a MBeanServer.
>- any company out there wishing to pay for my phone bill for time
> invested in Avalon (I may have to switch to water & bread soon)?
> (okay so maybe it's off-topic....)
;)
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]
