Hi to all, and thanks for your feedback, I've waited a little before to respond to start to look better at some of the Tomcat JMX features. I cross-post Pivot Developers here to give others some update.
> Costin > There is a servlet that dumps all JMX objects - in a strange format ( like > manifest or INI file - not hard to parse ). > Would be great ( and quite easy ) to make it also output json. > All information you want should be there - and much more. Exposing new data > is also easy. > You can also use some of the JMX access methods - RMI, etc. thanks for the info, for us reading json data is well supported, but we'll have to use jmx to set values I think. In any case, this could be a starting point. > Rainer > Trying to aim at the middle ground might trigger more interest. Being able to > remotely administer, but maybe not using a very high level configuration > management. That's something one could also discuss on the users list. I think this could be our right choice, thanks for the info. > AFAIK one of the problematic parts of the old admin webapp was getting > storeconfig into a working and maintainable state. In other words: how does > one correctly save changes applied to a configuration by a console? Pivot Applets / Applications (as a RIA) will run on Client, usually downloaded from the Server (maybe with a new, dedicated Console webapp of Tomcat), and some parts of it can also run inside the Server. We can also use a local storage, but in this case probably we have to call something on the server to make it (check, then) update config files, and force a reload. This discussion is very interesting for me, because you (Tomcat Developers) know very well what is needed, and what is to be done, so any info and suggestion is welcome. The idea to manage a Cluster of Tomcat instances is very interesting, but my only fear is that could be too much long for us. Also the idea of the json-jmx proxy is good. My first use case to try to address is some of most common operations, like: - list/manage applications and maybe server status - deploy/undeploy/start/stop applications - list/manage users - list/manage datasources - etc ... You think these features could start to give some value or many others are required ? After this, the main problem we have at Pivot is that currently the Developer Team is little, so starting with a long/complex project could be a problem (we have a lot of features to implement in Pivot), but doing something step by step could be a practical choice. I expect that Greg Brown, the Pivot Team Leader can join here and explain better its point of view. Thanks to all, Sandro --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
