I agree with JB. A lot of users run ActiveMQ embedded in Karaf, Tomcat, Glassfish, TomEE, Spring Boot, etc.
> On Nov 5, 2024, at 3:16 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi Ken, > > I don't say that you should test/use Karaf, it's just to illustrate > that's probably a runtime related topic. > In the case of "standalone" runtime (and probably webconsole), so it > might impact the users integrating ActiveMQ (for instance in a servlet > container or so). > We have to be careful in what we push in broker core, avoiding to > impact the runtimes. > > Regards > JB > > On Tue, Nov 5, 2024 at 7:04 AM Ken Liao <kenlia...@gmail.com> wrote: >> >> Thanks JB. I wasn't aware of using Karaf with ActiveMQ. Will try to set it >> up first and see what the experience looks like. >> >> Thanks, >> Ken >> >> On Fri, Nov 1, 2024 at 11:12 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> Hi Ken >>> >>> The behavior you describe is correct when using ActiveMQ standalone. >>> If you are running ActiveMQ in Karaf, you already have a behavior >>> similar to what you describe: the users/roles can be managed by in >>> Karaf realms, no need to restart the broker. >>> >>> I like your idea, but it should be optional as a lot of users >>> integrate ActiveMQ in their ecosystem, so with authentication plugin >>> to plug into their system. >>> >>> So, I agree with the proposal as long as the current plugins system is >>> still available. >>> I think we can implement what you are proposing as its own plugin >>> (including web console plugins). >>> >>> Regards >>> JB >>> >>> On Fri, Nov 1, 2024 at 8:07 AM Ken Liao <kenlia...@gmail.com> wrote: >>>> >>>> Hi ActiveMQ community, >>>> >>>> I am asking for opinion and buy-in on an idea I have lately before diving >>>> into implementation. The idea is a new user management experience in >>>> ActiveMQ Classic. >>>> >>>> Right now, the way to provision new users on ActiveMQ Classic with >>> default >>>> JAAS plugin (and assuming not using LDAP) is by changing a few >>>> configuration files and restarting the broker. There are a few drawbacks >>>> with the current approach: >>>> 1. Knowing which files to change and actually changing them correctly >>>> require technical knowledge and needs to be performed by someone who has >>>> access to the host servers. >>>> 2. It is prone to human error (typo ... etc) that can cause the broker to >>>> fail on startup. >>>> 3. Any change to users will require a reboot of the broker, which reduces >>>> the availability of the broker. >>>> >>>> Hence I am proposing a new user management experience that has two >>>> important improvements: >>>> 1. Broker users can be provisioned, removed and modified by an admin user >>>> (who may not have technical knowledge or access to the server host) using >>>> the web console of the broker. The admin can also use it to modify >>>> authorization policy of each user on different destination via intuitive >>>> UI. >>>> 2. Any change made will kick in real-time without broker restart. >>>> >>>> Would love to get the community's opinion, potential concern ... etc on >>> the >>>> idea before following up with a design / requirement proposal. >>>> >>>> What do you think? Thanks. >>>> >>>> Regards, >>>> Ken >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org >>> For additional commands, e-mail: dev-h...@activemq.apache.org >>> For further information, visit: https://activemq.apache.org/contact >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
