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
>
>
>

Reply via email to