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