Thanks Matt and JB for the feedback. That totally makes sense, I see your points and will keep that in mind.
Thanks, Ken On Tue, Nov 5, 2024 at 6:36 AM Matt Pavlovich <mattr...@gmail.com> wrote: > 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 > > >