JMX is very conceptually compatible with the ad hoc approach Jason and I had discussed last summer. Remember what I said about using a statistics object and a registry? From the JMX specification: "The MBean server is a registry for MBeans [in the application.]" Very similar concepts. Not that I would claim uniqueness. SNMP, /proc, and other schemes are all in the same pattern.
JMX is the right way to do this for James, since it is a standard, provides control, is embedded in Phoenix, is growing in use, and provides a replacement for the aging remote manager interface. > I imagine that the class doing the work would have a variable which > holds the statistic we care about. Classes. Plural. Lots of beans. :-) > This would cause SMTPHandler to refuse or defer some incoming > connections. Minor nit, but this is wrong. You need to understand the archtectural relationships between some of the components. The protocol handler is used after a new connection is established. Rejecting a new connection based upon busy state would happen elsewhere. As I've said before, please feel free to contribute. If you're interested in working on JMX for James, got for it. :-) Avalon has been using http://mx4j.sourceforge.net/. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
