> > Since Marco is proposing using an applet, a simple solution > would be > > to use the webserver security configuration to protect > access to the > > page containing the applet. > > What is to prevent someone from someone from running the > applet on their local system, and pointing it at an arbitrary > James server?
A firewall. Clearly this isn't going to work for everyone. The default James config could still have the JMX remoting disabled by default. > > The JMX Remote API spec, JSR 160 does include security features and > > MX4J does include a section on using a JMXAuthenticator. > > > I don't know if it is easy to use this via Phoenix but I can take a > > closer look if we agree on a JMX based approach. > > Let's be sure to coordinate this with the Avalon folks to > make sure that what we need is supported by the container. > We should probably move the JMX discussion to server-dev, but > I know that Stephen McConnell monitors both lists. I agree. James is heavily dependent on the container. I'd like to take a look at Merlin's JMX features but I'm working with the 2.x branch of James which does not have the Component/Service change which means I cannot use it with Merlin. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
