On Wed, Sep 16, 2026 at 10:36 AM Mark Thomas <[email protected]> wrote: > > Rémy, > > Being able to bring back the admin web application would be great. I > like the idea of maintaining it with LLMs. I guess we'd need some > standard prompts to use to review and update the app before a release to > pick up new/changed elements and attributes.
Indeed the admin webapp part of the app needs to be kept in sync, which is not too hard (it is doable without the tools I think, it's just a few arrays for some of the most specific objects). > If regular complete re-writes are a possibility then we just need to > make clear in the docs that this is a GUI intended for humans and there > are no guarantees of API stability. Do we direct tools to JMX or do we > experiment further with an LLM generated REST api? For tool use, I would say the ManagerServlet is the target (also the JMX proxy). It is used by the Ant tasks we provide, the Maven plugin was using that, and so on. So that's a strong hint that it should not be touched. The new webapp has the same screens comparable to HTMLManagerServlet, and for many features like deployment and session access, it extends that servlet (the LLM realized the app manipulation operations are complex so it was better to reuse the existing code). I didn't hear of anyone scripting that old gui itself (although it was mostly stable). This is basically an app for a phone (although it needs work to actually work on a phone), so yes I would assume it is normal to refresh it "often" rather than try to make it perfect. I'm pretty sure there was one, and so on, so this would be it. > I don't have much time to look at this right now. Are you thinking about > adding it to a Tomcat release? If so, in what form and on what timeline? Not sure. Rémy > Mark > > > On 15/09/2026 22:19, Rémy Maucherat wrote: > > Hi, > > > > 20 years ago, Tomcat had an admin webapp which could take over editing > > server.xml, used in conjunction with StoreConfig. If you don't know > > what it was, here's a link (in French, sorry): > > https://www.jmdoudoux.fr/java/dej/chap-tomcat.htm#tomcat-6 . > > StoreConfig was brought back already, however development and > > maintenance of an admin webapp was no longer worth it and it was fully > > removed in Tomcat 6. A revamped manager webapp was floated before, but > > for some reason it did not happen. So I tried with a LLM (Qwen 3.8 > > 27B). The goal was to make a modern, reactive (cough cough, as much as > > possible at least ...), "app style" webapp which would provide both > > the manager and the admin webapp functionality. > > > > I think the result (done over the weekend + yesterday) is actually > > decent and it seems usable. Iterating to fix a bug or to add missing > > features works well without busting everything. > > > > Internally the thing also looks "ok" (although I cannot judge the .js > > stuff ...). It is not meant to replace the existing manager webapp due > > to existing tool use. I tried it on my phone, and the dashboard looks > > good in portrait mode (the rest: nope, bad). It looks "ok" in > > landscape. Maybe the layout could be optimized further, but there's a > > lot of data to show on some pages so it seems a bit difficult. > > Basically, it's front end stuff and it seems to work, so I'm happy > > enough. And there's lots of tests. > > > > I think having this kind of functionality could be "ok" as long as the > > maintenance work stays minimal. It seems it could be maintained > > exclusively using LLMs so it could work. Given that LLMs are expected > > to improve further, it might also be beneficial to regularly replace > > it with a brand new full rewrite. UIs don't have to be as frozen as an > > API, only the general functionality has to be consistent. > > > > https://github.com/rmaucher/tomcat > > The code is almost exclusively in the modules/manager2. There's a > > little hack to make TLS config smoother. I don't like it much and I > > tried to remove it, but I understand how the LLM found that the TLS > > configuration sequence could be annoying when using a UI rather than > > editing server.xml. > > > > Rémy > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
