Cool! No worries then. My preferred option would be to ship James with JMX turned off. If you want it then turn it on - if to turn it on, then you asked for it...
I shall start to think a bit more about what and how to control and instrument James. I would like to JMX James 3.0 rather than v2 mainly because v3 is in dev and I may need to make some fairly serious changes to James internals. Any comments on this? Jason Webb Director iNovem Ltd > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: 18 June 2003 19:34 > To: James Developers List > Subject: RE: Server statistics (was: Personal IP blacklists) > > Jason, > > I suggest to you that the JMX MBeans are orthogonal from authenticated > user. > Let's get JMX into James, and let me go talk to Avalon about helping us > lock > out unauthorized users. In fact, they are voting today to give James > Committers access to the components area of their CVS module. > > We won't release James with JMX until we've secured it, but lets get the > instrumentation part of the project going. Fair enough? :-) > > --- Noel > > -----Original Message----- > From: Jason Webb [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 4:01 > To: 'James Developers List' > Subject: RE: Server statistics (was: Personal IP blacklists) > > > I'd still like to do this (give James real JMX usability), but I have > one hang-up with the current Avalon implementation in that I need Avalon > to provide authentication which it currently doesn't do. Once this is > done then I can start Mbean'ing up James properly for control. Without > this I won't start any work as it would James a serious security hole. > > My eventual goal is to instrument James as completely as possible :) > I have the JMX book and I am ready... > > -- Jason > > > -----Original Message----- > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > > Sent: 18 June 2003 08:05 > > To: James Developers List > > Subject: RE: Server statistics (was: Personal IP blacklists) > > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
