Re: Autogeneration or handcoding?
Noel J. Bergman wrote: Noel J. Bergman wrote: I am just getting ready to commit Steve Shorts JMX extensions. To where? MAIN? Well both MAIN and branch_2_1_fcs Ah, that's cool. :-) The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet Is this a build time process? I am possibly OK with the doclet approach (can you provide an example?) if it is strictly a build time issue. It is strictly a build-time issue. You place tag in the MBean interface like this for the DNSServerMBean: * @phoenix:mx-topic name=DNSServer The same thing is possible for .xinfo files and it is documented (rather well actually) at the phoenix site. I thought that this was not used because we for some reason did not want to introduce more tools or something. I don't know of any reason not to use a tool, but we should make sure of Avalon's plans. Hopefully they are maintaining compatibility as they add JMX into Merlin. I looked at http://avalon.apache.org/merlin, the Avalon Wiki, and the mailing lists, but couldn't find anything other than some e-mails back in September, so I am cc'ing Stephen to make sure we get a response. Typically james is deployed as a standalone server. It would be real easy to add a JMX server component and then declare a dependency on this under your management component. I.e. nothing stopping the setup of JMX based on the current released version of Merlin. In answer to the broader question about JMX support in Merlin - a prerequisite step is the introduction of a formal facilities model. Within Merlin a facility is just another component except that it is granted additional privs - in particular it has access to information about (a) the deployment environment, (b) the entire deployment meta-model. Using this information a facility can navigate the model looking for other components and quietly set things up (such as persistence handlers, remote transports, custom lifecycle handlers, etc.). A JMX facility will be provided that does exactly this - it will navigate the model looking for manageable components and register them for you automatically. Concerning the markup format - there are still some open questions here - in particular the possible usage of the phoenix model, or, using the QDox JMX tags, or, closer alignment with Geronimo. Cheers, Stephen. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autogeneration or handcoding?
On Sunday 15 February 2004 00:14, Noel J. Bergman wrote:
I am just getting ready to commit Steve Shorts JMX extensions.
To where? MAIN?
Well both MAIN and branch_2_1_fcs, is that not what you prefer?
or would you rather have that I wait until the merger has finished?
The patch removes the need to handcode the .mxinfo files by using the
Phoenix
supplied doclet
However for this to work we need to commit four additional .jar files
(Steve
places them in tools/lib which makes sense)
Is this a build time process? I am possibly OK with the doclet approach
(can you provide an example?) if it is strictly a build time issue.
It is strictly a build-time issue. You place tag in the MBean interface like
this for the DNSServerMBean:
/**
* An interface to expose James management functionality through JMX.
*
* @phoenix:mx-topic name=DNSServer
*/
public interface DNSServerMBean {
...
Then the .mxinfo files are autogenerated during the build process and put in
the james.jar.
The same thing is possible for .xinfo files and it is documented (rather well
actually) at the phoenix site.
I thought that this was not used because we for some reason did not want to
introduce more tools or something.
--Søren
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Autogeneration or handcoding?
Noel J. Bergman wrote: I am just getting ready to commit Steve Shorts JMX extensions. To where? MAIN? Well both MAIN and branch_2_1_fcs Ah, that's cool. :-) The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet Is this a build time process? I am possibly OK with the doclet approach (can you provide an example?) if it is strictly a build time issue. It is strictly a build-time issue. You place tag in the MBean interface like this for the DNSServerMBean: * @phoenix:mx-topic name=DNSServer The same thing is possible for .xinfo files and it is documented (rather well actually) at the phoenix site. I thought that this was not used because we for some reason did not want to introduce more tools or something. I don't know of any reason not to use a tool, but we should make sure of Avalon's plans. Hopefully they are maintaining compatibility as they add JMX into Merlin. I looked at http://avalon.apache.org/merlin, the Avalon Wiki, and the mailing lists, but couldn't find anything other than some e-mails back in September, so I am cc'ing Stephen to make sure we get a response. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autogeneration or handcoding?
I don't know of any reason not to use a tool, but we should make sure of Avalon's plans. Hopefully they are maintaining compatibility as they add JMX into Merlin. I looked at http://avalon.apache.org/merlin, the Avalon Wiki, and the mailing lists, but couldn't find anything other than some e-mails back in September, so I am cc'ing Stephen to make sure we get a response. Fine, I will wait for his response. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Autogeneration or handcoding?
Hi all, I am just getting ready to commit Steve Shorts JMX extensions. There is a little issue with it I like to get second opinions on. The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet which handles this automagically from Javadoc tags in the code. However for this to work we need to commit four additional .jar files (Steve places them in tools/lib which makes sense), the question is, do we want this or do we want handcoded mxinfo files. I suspect we want the handcoded ones as we also use handcoded .xinfo files, which could also have been autogenerated. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Autogeneration or handcoding?
I am just getting ready to commit Steve Shorts JMX extensions. To where? MAIN? The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet However for this to work we need to commit four additional .jar files (Steve places them in tools/lib which makes sense) Is this a build time process? I am possibly OK with the doclet approach (can you provide an example?) if it is strictly a build time issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
