Hi Łukasz- Yes, the DTO approach is the way. I’ve got a design that works with essentially the models from the runtime-config plugin (as they map 1:1) to the current broker beans. Long term, there is value in moving away from getter/setter properties to a full-config-bean to support multi-field changes to be refreshed all-at-once.
That being said, there are one or two things that I am working on to unblock the ability to do this: 1. Move away from Spring configuration for Jetty configuration (In-progress PR: https://github.com/apache/activemq/pull/1344) 2. Move SSLContext from Thread Local (remove all Thread Local references) to be more of a declared bean for config 3. Update JAAS API to the JDK 21 baseline. Having looked at a similar set of change with Apache Karaf, a couple things to be expecting: 1. To support JDK 25 we need a branch that is JDK-21 minimum b/c JDK 17 does not support the new JAAS API — specifically Subject.current() 2. The move to config DTOs will start breaking Spring-based new properties that we currently get “for free” 3. Configuration conversion tools would be needed for a new config system in order to support transitioning existing users to a new config-based solution. Anyone looking to help move this along is encouraged start by helping me fix the Jetty 12 conversion. Checkout my Jetty 12 branch and help me clean-up the JSP wiring (I am not an expert in that area). I’ll fix the hacky-ness of Jetty Spring bean itself, but I need help fixing the JSP wiring so the pages render. Thanks, Matt Pavlovich > On Sep 26, 2025, at 11:06 AM, Łukasz Dywicki <[email protected]> wrote: > > Relying on JMX is such a burden, and doing it with Jolokia is not any > smaller. If anyone does administrative interface over way with "remote" JMX > connection, then it ends up with Java/JMX/RMI serialization just to serve a > JSON/RPC layer on top of it. Its not a bad idea, but it has its drawbacks as > well. The JMX/RMI connection is never ending trouble due to dynamic port > allocation, it brings also additional security risks associated with JMX, > poorly documented/explored JMX security features, requires mapping of data to > JMX primitives, plus imposes limitations on the flexibility of operations as > they need to first fit JMX to become available through REST. > I'm not quite sure how the paging is working with Jolokia and JMX, I know its > doable, but given all above I'd rather write another set of DTOs to flush > broker state rather than rely on the JMX. > > Best, > Łukasz > > > On 9/17/25 20:41, Ken Liao wrote: >> +1 I think building admin APIs for ActiveMQ Classic and then moving the web >> console to a separate repo is a good idea. Furthermore, by having the admin >> APIs it unlocks other opportunities such as MCP server for operating the >> broker. >> Thanks, >> Ken >> On Wed, Sep 17, 2025 at 8:22 AM Endre Stølsvik <[email protected]> wrote: >>> Sorry, but I just have to drive-by comment on this: >>> I would really suggest just making it out of JS/HTML/CSS, not using any >>> frameworks at all. A full-on "SPA-alike" NPM+Node-built webapp should at >>> least definitely not be done, IMHO. >>> >>> Kind regards, >>> Endre Stølsvik >>> >>> On Wed, Sep 17, 2025 at 5:04 PM Matt Pavlovich <[email protected]> >>> wrote: >>> >>>> I am in favor of an improvement in a new web console for out-of-the-box >>>> experience for ActiveMQ. I think an easier first pass is a re-skin and >>>> remove of Spring Web/MVC from the dependency chain. >>>> >>>> I’m not generally in favor of hosting a Javascript-based web console, >>>> since the ecosystem is riddled with issues and constant overhaul, but I >>>> would be -0 on if others wish to tackle it. >>>> >>>> Regarding using Hawtio: -1 >>>> >>>> Matt Pavlovich >>>> >>>>> On Sep 17, 2025, at 5:26 AM, Andy Taylor <[email protected]> >>> wrote: >>>>> >>>>> If you are looking to use Jolokia have you thought of using HawtIO? >>> This >>>> is >>>>> what the Artemis console is built on, it would be pretty easy to >>>>> bootstrap something and you get a lot out of the box for free such as >>>>> Authentication etc. Just an idea! >>>>> >>>>> >>>>> Andy >>>>> >>>>> On Wed, 17 Sept 2025 at 06:49, Jean-Baptiste Onofré <[email protected]> >>>> wrote: >>>>> >>>>>> Hi folks, >>>>>> >>>>>> I started to write a new web console for ActiveMQ Classic, powered by >>>>>> reactjs and ant.design. >>>>>> >>>>>> More than a more "modern/professional" look'n feel, the purpose is >>> also >>>> to: >>>>>> 1. Be able to manage multiple brokers in one console >>>>>> 2. Have the web console decoupled from the brokers (interesting for >>>>>> Kubernetes deployment) >>>>>> 3 Integrate with Jolokia (instead of directly JMX) >>>>>> >>>>>> I would like to propose this for ActiveMQ Classic 7, removing the >>>>>> current webconsole (also removing the spring controller dependency, >>>>>> etc). >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> For further information, visit: https://activemq.apache.org/contact >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> For further information, visit: https://activemq.apache.org/contact >>>> >>>> >>>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > >
