Janne --

How stable is the ui.admin package? It seems a little vestigial at the moment. Tonight, after months of procrastinating, I twiddled with jspwiki.properties and fired up admin/Admin.jsp. (I could not, frankly, get the "add user" command to work.)

In looking through the package, docs and interface, I have a few comments, in no particular order:

1. I like the fact that you are using JMX. I successfully fired up a remote JMX client (jconsole) to poke around the MBeans (i.e., AdminBeans).

2. The need for a separate package (com.ecyrd.jspwiki.ui.admin.bean) seems unclear. It seems to me that it would be a better strategy to AdminBean/MBean-enable existing classes rather than create a whole set of parallel packages. For example, wouldn't it be better to add JMX interfaces to the various 'Manager classes (e.g., UserManager, PageManager, SessionMonitor, etc...)?

3. Making JMX an interface for existing manager classes would enable them to register themselves, removing hard-coding in AdminBeanManager.

4. The AdminBean "type" property seems arbitrary. It's also better handled as a typesafe enum. Proof point: the case statement in getJMXTitleString() is pretty ugly.

5. JSP admin interface isn't real functional. And it's yet another browser-accessible interface to have to patch, filter, validate, etc... It would be better to just kill it, and provide simple instructions for enabling a remote JMX client. We could add JMX interfaces for existing manager classes *far* faster than we could add equivalent JSP interfaces.

6. I am very interested in MBean types like TimerMBean. These could allow us, for example, to replace a lot of our background thread code with simple TimerMBeans. CounterMonitorMBeans would be very useful for things like account logouts.

7. It looks like we don't create JMX ObjectNames that are distinct between wiki instances. Should we? An easy way to do this might be to append wiki=_____ to the object name key property. That wouldn't guarantee that registered beans would be completely distinct, though; maybe add the webapp context name?

Janne, I don't mean to come across as overly critical of your existing efforts. My comments are mostly meant to stimulate a bit of discussion for 2.8 and 3.0.

Andrew

Reply via email to