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]
