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.)
It's not stable at all. It's mostly an experiment (that's why you need to twiddle with the property file to enable it.)
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...)?
The reason why I wanted to keep it separate was that it was far cleaner this way, as the API is unstable. I didn't want to be messing with stable code while development was ongoing.
Also, since JMX practically requires JDK 1.5 to be usable, I didn't want to introduce JDK1.5 dependencies to classes which are supposed to be running with JDK 1.4.
3. Making JMX an interface for existing manager classes would enable them to register themselves, removing hard-coding in AdminBeanManager.
I never got around to making a self-registration system - that's why the hardcoding. However, notice that filters and editors can already declare themselves to be enabling AdminBean, after which they're automatically added. Our internal routines don't really do that (but it should be pretty easy to do just what Stripes does, and add all classes which just implement AdminBean. No need for self- registration; just a bit of Reflection.)
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.
It's remnants of old code that I never really got around to cleaning away. I don't think we even want an enum; it should be a dynamical property or something.
(And you get those case statements everywhere prior to JDK 5 code anyway; take a look at JSR-170 PropertyType for example ;-)
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.
Nope. JMX does not work through firewalls, except with great pain. For me, management through firewalls and on the regular browser is an absolute necessity (ever tried running an JMX administrative client on a mobile phone, or on a hostile network which thinks their god- given right is to filter out all but HTTP or HTTPS traffic [yes, including SSH and VPN]? This is very common on a lot of corporate networks...)
Also, using a browser-based interface allows you to use things like AJAX to enhance the experience over the transactional experience of JMX.
I also think that we will need to enable the ability for average wikiusers who are given Admin powers to also govern the wiki. I don't think JMX allows for such fine-grained access controls as we can give on JSPWiki - and I would certainly hate to start poking holes at my firewall for each user whom I want to be able to administer jspwiki.org! It's just not safe, you know :-)
However, since the JMX model is well thought out and useful, I figured that it's a good model to base even HTML creation on top of, while still retaining compatibility with a majority of Java admin tools out there.
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.
I would hate to build strong dependencies on JDK 1.5 code before we actually agree to use it (that is, 3.0).
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?
Probably we should.
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.
The Admin interface is largely an experiment in producing something which can generate both a JMX and an XHTML UI at minimum effort, offering the flexibility for AdminBean writers to choose whether they want to just stick to an JMX API or whether they want to produce the XHTML UI fully by themselves. This is really the key design criteria: make it easy to build an AdminBean (essentially implementing a few getters and setters; check out SimpleMBean and SimpleAdminBean, and hopefully it should be possible to create a WikiFormAdminBean as well), while allowing AdminBean writers the ability to add a complex HTML interface on top of it if they want.
One of the UI's I really admire in this respect is the WordPress UI - plugins can simply have an admin component, which they can add to the UI. Very low-stress to the user and the plugin writer, though I'm sure a lot of effort was put into designing the UI routines themselves.
/Janne
