[VOTE] Archive unused or out-of-date repos
Following up from the previous discussion thread on this subject, I'd like to propose a vote for archiving the following repos: - activemq-stomp - https://github.com/apache/activemq-stomp - activemq-activeio - https://github.com/apache/activemq-activeio - activemq-web - https://github.com/apache/activemq-web - activemq-nms-ems - https://github.com/apache/activemq-nms-ems - activemq-nms-xms - https://github.com/apache/activemq-nms-xms - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq Here's my +1. Justin
Re: rename activemq-artemis-console-plugin repo
I opened INFRA-25741 [1] to get the old repo deleted. Justin [1] https://issues.apache.org/jira/browse/INFRA-25741 On Tue, Apr 23, 2024 at 5:09 AM Andy Taylor wrote: > just to wrap things up I have now moved everything I need to so the old > repo can be deleted > > On Mon, 22 Apr 2024 at 18:18, Andy Taylor wrote: > > > Many thanks Justin > > > > On Mon, 22 Apr 2024, 15:43 Justin Bertram, wrote: > > > >> Done. Repo is available at: > >> > >> https://github.com/apache/activemq-artemis-console > >> > >> > >> Justin > >> > >> On Mon, Apr 22, 2024 at 4:38 AM Andy Taylor > >> wrote: > >> > >> > @Justin Bertram If you could go ahead and > create > >> > the new repo then give me some time to move stuff over before deleting > >> the > >> > current one. Just to confirm the new repo name is > >> 'activemq-artemis-console' > >> > > >> > On Thu, 18 Apr 2024 at 15:32, Andy Taylor > >> wrote: > >> > > >> >> makes sense to me, lets give it a while for people to comemnt > >> >> > >> >> On Thu, 18 Apr 2024 at 15:30, Robbie Gemmell < > robbie.gemm...@gmail.com > >> > > >> >> wrote: > >> >> > >> >>> Renaming it seems reasonable if it is not actually going to be just > a > >> >>> plugin anymore. > >> >>> > >> >>> If everyone agrees, creating a new repo and deleting the old one > might > >> >>> be the quicker approach, since we can do the former ourselves whilst > >> >>> the rest needs Infra to handle. They might also be more willing to > >> >>> remove the other without a vote if pointed to discussion and a > >> >>> replacement repo already existing. > >> >>> > >> >>> On Thu, 18 Apr 2024 at 12:41, Andy Taylor > >> >>> wrote: > >> >>> > > >> >>> > Devs, > >> >>> > > >> >>> > Recently we had a new repo created for the new Artemis console I > am > >> >>> working > >> >>> > on. At the time the console was going to be a plugin similar to > >> what we > >> >>> > have, however after some design changes it is not more of an > >> extension > >> >>> of > >> >>> > hawtIO and not shipped as a plugin. The benefit here is that we > now > >> >>> only > >> >>> > need to deploy 1 endpoint in Jetty. > >> >>> > > >> >>> > That being the case I would like to rename the repo, or create a > new > >> >>> one, > >> >>> > named activemq-artemis-console which falls more in line with what > >> the > >> >>> > project actually is. > >> >>> > > >> >>> > What do you all think? > >> >>> > > >> >>> > If there are no objections I will get this done next week? > >> >>> > > >> >>> > Andy T > >> >>> > >> >> > >> > > >
Re: rename activemq-artemis-console-plugin repo
Done. Repo is available at: https://github.com/apache/activemq-artemis-console Justin On Mon, Apr 22, 2024 at 4:38 AM Andy Taylor wrote: > @Justin Bertram If you could go ahead and create > the new repo then give me some time to move stuff over before deleting the > current one. Just to confirm the new repo name is 'activemq-artemis-console' > > On Thu, 18 Apr 2024 at 15:32, Andy Taylor wrote: > >> makes sense to me, lets give it a while for people to comemnt >> >> On Thu, 18 Apr 2024 at 15:30, Robbie Gemmell >> wrote: >> >>> Renaming it seems reasonable if it is not actually going to be just a >>> plugin anymore. >>> >>> If everyone agrees, creating a new repo and deleting the old one might >>> be the quicker approach, since we can do the former ourselves whilst >>> the rest needs Infra to handle. They might also be more willing to >>> remove the other without a vote if pointed to discussion and a >>> replacement repo already existing. >>> >>> On Thu, 18 Apr 2024 at 12:41, Andy Taylor >>> wrote: >>> > >>> > Devs, >>> > >>> > Recently we had a new repo created for the new Artemis console I am >>> working >>> > on. At the time the console was going to be a plugin similar to what we >>> > have, however after some design changes it is not more of an extension >>> of >>> > hawtIO and not shipped as a plugin. The benefit here is that we now >>> only >>> > need to deploy 1 endpoint in Jetty. >>> > >>> > That being the case I would like to rename the repo, or create a new >>> one, >>> > named activemq-artemis-console which falls more in line with what the >>> > project actually is. >>> > >>> > What do you all think? >>> > >>> > If there are no objections I will get this done next week? >>> > >>> > Andy T >>> >>
Re: [DISCUSS] Delete unused or out-of-date repos
I agree 100% with the following: Good to archive/read-only: - activemq-activeio - activemq-nms-ems - activemq-nms-xms - activemq-nms-zmq - activemq-nms-msmq Should stay open for now: - activemq-protobuf I still think these are worth deleting: - activemq-stomp - activemq-web The activemq-stomp repo pretty clearly became https://github.com/stomp/stomp-spec. See this commit [1] for details. I don't see any value in keeping this repo, even in read-only form. The activemq-web repo was an intermediate dump that eventually became https://github.com/apache/activemq-website/. Again, I don't see any value in keeping this repo. I'm iffy on activemq-nms-stomp and could go either way (i.e. archiving or keeping open). I certainly agree that STOMP is a useful protocol, but anybody is still free to use it even if this repo is archived. It has good support across platforms and languages. It's not clear to me why anybody would use the NMS STOMP implementation when AMQP and OpenWire implementations exist. Furthermore, if someone really wanted to use STOMP why not simply use one of the existing .NET STOMP clients? Nobody has filed a bug or asked for a release in ages as far as I know. Justin [1] https://github.com/stomp/stomp-spec/commit/5e8edb9cd52927bbdd3acee5cf9940c571ef00b7 On Thu, Apr 18, 2024 at 8:45 PM Matt Pavlovich wrote: > Hi Justin- > > What about moving several to archived/read-only vs delete? Or at least > archive/read-only for a period of time before deleting them altogether? > > Good to archive/read-only: > - [x] activemq-stomp (looks like stomp website) > - [x] activemq-web (looks like deprecated repo activemq-website is current) > - [x] activemq-activeio I removed this as an active dependency last year > ahead of 6.0.0 release. > - [x] activemq-nms.. ems, xms, zmq and msmq imho, these are good to > archive— mostly unmaintained and deprecated/older protocols and brokers. > > Might be good to keep open: > - [x] activemq-nms-stomp - STOMP is still a useful protocol, but the code > module is mostly unmaintained > > Should stay open for now: > - [x] activemq-protobuf — This is still referenced by ActiveMQ Classic. I > plan to re-home this back to the main tree for JDK modernization and > protobuf upgrade, etc. but we there may be some unforeseen reason to > release an update out of this repo. > > Thanks! > Matt Pavlovich > > > On Apr 18, 2024, at 2:40 PM, Justin Bertram wrote: > > > > During the process of researching the proposed move to GitHub Issues I > > reviewed all ActiveMQ Git repos [1]. I noticed a handful that haven't > been > > updated in a long time and appear to be defunct: > > > > - activemq-stomp - https://github.com/apache/activemq-stomp > > - activemq-activeio - https://github.com/apache/activemq-activeio > > - activemq-protobuf - https://github.com/apache/activemq-protobuf > > - activemq-web - https://github.com/apache/activemq-web > > - activemq-nms-ems - https://github.com/apache/activemq-nms-ems > > - activemq-nms-xms - https://github.com/apache/activemq-nms-xms > > - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq > > - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq > > - activemq-nms-stomp* - *https://github.com/apache/activemq-nms-stomp > > > > Most of these repos haven't seen a meaningful update in almost a decade. > > Does anybody have concerns with deleting any of these? > > > > My goal here is to simplify our code footprint and clarify what > code-bases > > are functional and actively maintained. > > > > > > Justin > > > > [1] > > > https://github.com/orgs/apache/repositories?language==activemq==all > >
Re: [DISCUSS] Delete unused or out-of-date repos
Agreed. Good call on the archiving. Justin On Thu, Apr 18, 2024 at 3:58 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > I don't think it's a good idea to delete anything unless it's just an empty > repo so we can preserve the history. > > I think the standard practice is to instead ask infra to archive the repos > and they become read only. We did that with Apollo: > https://github.com/apache/activemq-apollo > > > > On Thu, Apr 18, 2024 at 3:40 PM Justin Bertram > wrote: > > > During the process of researching the proposed move to GitHub Issues I > > reviewed all ActiveMQ Git repos [1]. I noticed a handful that haven't > been > > updated in a long time and appear to be defunct: > > > > - activemq-stomp - https://github.com/apache/activemq-stomp > > - activemq-activeio - https://github.com/apache/activemq-activeio > > - activemq-protobuf - https://github.com/apache/activemq-protobuf > > - activemq-web - https://github.com/apache/activemq-web > > - activemq-nms-ems - https://github.com/apache/activemq-nms-ems > > - activemq-nms-xms - https://github.com/apache/activemq-nms-xms > > - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq > > - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq > > - activemq-nms-stomp* - *https://github.com/apache/activemq-nms-stomp > > > > Most of these repos haven't seen a meaningful update in almost a decade. > > Does anybody have concerns with deleting any of these? > > > > My goal here is to simplify our code footprint and clarify what > code-bases > > are functional and actively maintained. > > > > > > Justin > > > > [1] > > > > > https://github.com/orgs/apache/repositories?language==activemq==all > > >
[DISCUSS] Delete unused or out-of-date repos
During the process of researching the proposed move to GitHub Issues I reviewed all ActiveMQ Git repos [1]. I noticed a handful that haven't been updated in a long time and appear to be defunct: - activemq-stomp - https://github.com/apache/activemq-stomp - activemq-activeio - https://github.com/apache/activemq-activeio - activemq-protobuf - https://github.com/apache/activemq-protobuf - activemq-web - https://github.com/apache/activemq-web - activemq-nms-ems - https://github.com/apache/activemq-nms-ems - activemq-nms-xms - https://github.com/apache/activemq-nms-xms - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq - activemq-nms-stomp* - *https://github.com/apache/activemq-nms-stomp Most of these repos haven't seen a meaningful update in almost a decade. Does anybody have concerns with deleting any of these? My goal here is to simplify our code footprint and clarify what code-bases are functional and actively maintained. Justin [1] https://github.com/orgs/apache/repositories?language==activemq==all
Re: [PROPOSAL] Enable GH issues
I removed you from the list, Arun.
Justin
On Thu, Apr 18, 2024 at 11:45 AM arun rapaka wrote:
> Can someone please remove me from this group
>
> On Thu, 18 Apr 2024 at 7:57 PM, Bruce Snyder
> wrote:
>
> > Good question, Chris. I don't believe so and I agree allowing discussions
> > in PRs is critical.
> >
> > Bruce
> >
> > On Thu, Apr 18, 2024 at 7:40 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > Is there anything stopping us from enabling Github Discussions for now?
> > It
> > > seems like we had consensus on that part.
> > >
> > > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich
> > wrote:
> > >
> > > > Robbie/JB-
> > > >
> > > > Good calls outs, thanks! I did not mean to skew into contribution
> guide
> > > as
> > > > far as I did. I will take a pass at cleaning up.
> > > >
> > > > Thanks,
> > > > Matt
> > > >
> > > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell <
> > robbie.gemm...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > The security bits are also detailed in all the repositories already
> > by
> > > > > default at the org level, e.g
> > > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file
> (or
> > > > > repositories can define their own policy, e.g
> > > > > https://github.com/apache/activemq/?tab=security-ov-file#readme ).
> > > > > Though we can of course make references to it clearer.
> > > > >
> > > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > > wrote:
> > > > >>
> > > > >> Hi Matt
> > > > >>
> > > > >> Imho, we are mixing two topics here:
> > > > >> 1. The ticket management system
> > > > >> 2. The contribution guide
> > > > >>
> > > > >> So, let me try to clarify:
> > > > >>
> > > > >> [PROPOSAL]
> > > > >>
> > > > >> I'm in favor of GH Issues, but we don't yet have a strong
> consensus
> > > > >> about that. I would propose a new thread about that to give a
> chance
> > > > >> to anyone to speak, and move to a vote.
> > > > >>
> > > > >> [README/CONTRIBUTION GUIDE]
> > > > >>
> > > > >> First, ICLA is not strictly required before committership (the
> > Apache
> > > > >> 2.0 license already covered contributor, it has been discussed on
> > > > >> LEGAL Jira).
> > > > >> Second, you don't report security issues on a mailing list, you go
> > to
> > > > >> secur...@apache.org.
> > > > >> Explaining how to report issue, create PR, contribute (e.g.
> > > > >> contribution guide) is fine and welcome.
> > > > >>
> > > > >> Regards
> > > > >> JB
> > > > >>
> > > > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich <
> mattr...@gmail.com>
> > > > wrote:
> > > > >>>
> > > > >>> @dev-
> > > > >>>
> > > > >>> I appreciate all the good feedback and discussion. A number of
> good
> > > > points, suggestions and perspectives. Overall, I see an uptick in
> > > community
> > > > interest in contributing to ActiveMQ and that’s a great thing! I
> > believe
> > > > that modernizing the toolkit, reducing contribution friction and
> > lowering
> > > > load on committers/PMC will help keep the community healthy going
> > forward
> > > > =).
> > > > >>>
> > > > >>> I've made a pass at summarizing the points and take-aways from
> the
> > > > [DISCUSS] thread below. Please reply with suggested add/edit/removes.
> > > > >>>
> > > > >>> [Key community Use Cases]
> > > > >>>
> > > > >>> UC-1. Issue - User opens an Issue and may or may not intend (or
> be
> > > > able) to produce a PR to address the report.
> > > > >>>
> > > > >>> UC-2. PR-onl - User opens a PR without an Issue to address their
> > > > requested fix.
> > > > >>>
> > > > >>> UC-3. Security report - User identifies a security issue and
> needs
> > to
> > > > report
> > > > >>>
> > > > >>>
> > > > >>> [Proposal]
> > > > >>>
> > > > >>> Action-1. Enable GH issues and flip JIRA to read-only
> > > > >>>
> > > > >>> Action-2. Update README in repo to be more of a 'how to engage
> with
> > > > the community' vs a project overview
> > > > >>>
> > > > >>>
> > > > >>> [Update README document to include]
> > > > >>>
> > > > >>> Update-1. Provide a link for users to create an issue
> > > > >>>
> > > > >>> Update-2. Provide a link to the mailing list for reporting a
> > security
> > > > issue
> > > > >>>
> > > > >>> Update-3. Provide a link for users to submit a CLA
> > > > >>>
> > > > >>>
> > > > >>> [Committer/PMC operating]
> > > > >>>
> > > > >>> Op-A. For use case #2 where user creates a PR without an issue,
> > > before
> > > > approval committer/pmc may instruct contributor to provide signed CLA
> > and
> > > > open a corresponding issue if the complexity warrants. The PR comment
> > can
> > > > then be updated with the issue id for reference and linking.
> > > > >>>
> > > > >>> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR
> > for
> > > > releases.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Matt Pavlovich
> > > >
> > > >
> > >
> >
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > http://bsnyder.org/
Re: [PROPOSAL] Enable GH issues
I definitely agree with starting a new [DISCUSS] thread about GitHub Discussions. Justin On Thu, Apr 18, 2024 at 11:11 AM Robbie Gemmell wrote: > We should start a new thread about Discussions so it can be clearly > and specifically discussed..i.e not on this thread or the other > previous thread both originally about Issues. > > On Thu, 18 Apr 2024 at 16:32, Christopher Shannon > wrote: > > > > I think overall it would be a positive thing, it gives a place for people > > to ask questions without having to raise a Jira. > > > > I guess the one downside is it would be something else to > monitor...there's > > already Jira, Slack, and the mailing lists. > > > > I think one thing that would be helpful for monitoring is for the > > discussions to be mirrored to email so people can monitor it in one spot, > > and even respond to by email if they want. I assume that the discussions > > can be emailed just like the notifications for PRs so that people don't > > need to check. I'm not sure if it would be better for the discussion > > threads to be mixed in with the existing notifications for PRs or > another > > mailing list. We can always set up filters so sharing the existing > > notification list is probably ok. > > > > On Thu, Apr 18, 2024 at 10:50 AM Justin Bertram > wrote: > > > > > Enabling GitHub Discussions is not something we've really discussed > > > thoroughly. I mentioned it in my review only briefly as a "future > > > consideration." I don't think we've got consensus yet. > > > > > > > > > Justin > > > > > > On Thu, Apr 18, 2024 at 8:47 AM Christopher Shannon < > > > christopher.l.shan...@gmail.com> wrote: > > > > > > > Is there anything stopping us from enabling Github Discussions for > now? > > > It > > > > seems like we had consensus on that part. > > > > > > > > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich > > > wrote: > > > > > > > > > Robbie/JB- > > > > > > > > > > Good calls outs, thanks! I did not mean to skew into contribution > guide > > > > as > > > > > far as I did. I will take a pass at cleaning up. > > > > > > > > > > Thanks, > > > > > Matt > > > > > > > > > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell < > > > robbie.gemm...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > The security bits are also detailed in all the repositories > already > > > by > > > > > > default at the org level, e.g > > > > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file > (or > > > > > > repositories can define their own policy, e.g > > > > > > https://github.com/apache/activemq/?tab=security-ov-file#readme > ). > > > > > > Though we can of course make references to it clearer. > > > > > > > > > > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré < > j...@nanthrax.net> > > > > > wrote: > > > > > >> > > > > > >> Hi Matt > > > > > >> > > > > > >> Imho, we are mixing two topics here: > > > > > >> 1. The ticket management system > > > > > >> 2. The contribution guide > > > > > >> > > > > > >> So, let me try to clarify: > > > > > >> > > > > > >> [PROPOSAL] > > > > > >> > > > > > >> I'm in favor of GH Issues, but we don't yet have a strong > consensus > > > > > >> about that. I would propose a new thread about that to give a > chance > > > > > >> to anyone to speak, and move to a vote. > > > > > >> > > > > > >> [README/CONTRIBUTION GUIDE] > > > > > >> > > > > > >> First, ICLA is not strictly required before committership (the > > > Apache > > > > > >> 2.0 license already covered contributor, it has been discussed > on > > > > > >> LEGAL Jira). > > > > > >> Second, you don't report security issues on a mailing list, you > go > > > to > > > > > >> secur...@apache.org. > > > > > >> Explaining how to report issue, create PR, contribute (e
Re: [PROPOSAL] Enable GH issues
Enabling GitHub Discussions is not something we've really discussed thoroughly. I mentioned it in my review only briefly as a "future consideration." I don't think we've got consensus yet. Justin On Thu, Apr 18, 2024 at 8:47 AM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Is there anything stopping us from enabling Github Discussions for now? It > seems like we had consensus on that part. > > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich wrote: > > > Robbie/JB- > > > > Good calls outs, thanks! I did not mean to skew into contribution guide > as > > far as I did. I will take a pass at cleaning up. > > > > Thanks, > > Matt > > > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell > > > wrote: > > > > > > The security bits are also detailed in all the repositories already by > > > default at the org level, e.g > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file (or > > > repositories can define their own policy, e.g > > > https://github.com/apache/activemq/?tab=security-ov-file#readme ). > > > Though we can of course make references to it clearer. > > > > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré > > wrote: > > >> > > >> Hi Matt > > >> > > >> Imho, we are mixing two topics here: > > >> 1. The ticket management system > > >> 2. The contribution guide > > >> > > >> So, let me try to clarify: > > >> > > >> [PROPOSAL] > > >> > > >> I'm in favor of GH Issues, but we don't yet have a strong consensus > > >> about that. I would propose a new thread about that to give a chance > > >> to anyone to speak, and move to a vote. > > >> > > >> [README/CONTRIBUTION GUIDE] > > >> > > >> First, ICLA is not strictly required before committership (the Apache > > >> 2.0 license already covered contributor, it has been discussed on > > >> LEGAL Jira). > > >> Second, you don't report security issues on a mailing list, you go to > > >> secur...@apache.org. > > >> Explaining how to report issue, create PR, contribute (e.g. > > >> contribution guide) is fine and welcome. > > >> > > >> Regards > > >> JB > > >> > > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich > > wrote: > > >>> > > >>> @dev- > > >>> > > >>> I appreciate all the good feedback and discussion. A number of good > > points, suggestions and perspectives. Overall, I see an uptick in > community > > interest in contributing to ActiveMQ and that’s a great thing! I believe > > that modernizing the toolkit, reducing contribution friction and lowering > > load on committers/PMC will help keep the community healthy going forward > > =). > > >>> > > >>> I've made a pass at summarizing the points and take-aways from the > > [DISCUSS] thread below. Please reply with suggested add/edit/removes. > > >>> > > >>> [Key community Use Cases] > > >>> > > >>> UC-1. Issue - User opens an Issue and may or may not intend (or be > > able) to produce a PR to address the report. > > >>> > > >>> UC-2. PR-onl - User opens a PR without an Issue to address their > > requested fix. > > >>> > > >>> UC-3. Security report - User identifies a security issue and needs to > > report > > >>> > > >>> > > >>> [Proposal] > > >>> > > >>> Action-1. Enable GH issues and flip JIRA to read-only > > >>> > > >>> Action-2. Update README in repo to be more of a 'how to engage with > > the community' vs a project overview > > >>> > > >>> > > >>> [Update README document to include] > > >>> > > >>> Update-1. Provide a link for users to create an issue > > >>> > > >>> Update-2. Provide a link to the mailing list for reporting a security > > issue > > >>> > > >>> Update-3. Provide a link for users to submit a CLA > > >>> > > >>> > > >>> [Committer/PMC operating] > > >>> > > >>> Op-A. For use case #2 where user creates a PR without an issue, > before > > approval committer/pmc may instruct contributor to provide signed CLA and > > open a corresponding issue if the complexity warrants. The PR comment can > > then be updated with the issue id for reference and linking. > > >>> > > >>> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR for > > releases. > > >>> > > >>> Thanks, > > >>> Matt Pavlovich > > > > >
Re: rename activemq-artemis-console-plugin repo
I can create a new repo, but I can't delete the old one myself. I'll need to get infra to do that. Justin On Thu, Apr 18, 2024 at 6:50 AM Andy Taylor wrote: > Devs, > > Recently we had a new repo created for the new Artemis console I am working > on. At the time the console was going to be a plugin similar to what we > have, however after some design changes it is not more of an extension of > hawtIO and not shipped as a plugin. The benefit here is that we now only > need to deploy 1 endpoint in Jetty. > > That being the case I would like to rename the repo, or create a new one, > named activemq-artemis-console which falls more in line with what the > project actually is. > > What do you all think? > > If there are no objections I will get this done next week? > > Andy T >
Re: ASF board report due by Tues, April 9 - new procedure, please read
I added detail about Artemis based on JB's draft.
I wondered if we might add a note about the fact we're considering moving
to GitHub Issues, but I wasn't sure that's something the board would care
about, and I wasn't sure where to add it.
Justin
On Thu, Apr 4, 2024 at 8:56 AM Jean-Baptiste Onofré wrote:
> Hi Bruce,
>
> I created a new draft (based on yours) containing ActiveMQ "classic"
> details.
>
> Regards
> JB
>
> On Mon, Apr 1, 2024 at 3:48 PM Bruce Snyder
> wrote:
> >
> > Hi folks,
> >
> > It is that time once again to assemble the latest ASF board report. As
> > mentioned previously, I would like us to begin using the Reporter tool to
> > assemble reports to the ASF board. The idea being that anyone with access
> > to the Reporter tool can log in and enter their contributions directly
> to a
> > given report. We will no longer be assembling the report using git.
> >
> > As you contribute to the report, you can reflow sections and then save
> your
> > contributions as a draft. This will leave the report in draft form (i.e.
> > not published). When the report is due, the PMC chair will log in to
> > Reporter to review and finalize the report as well as publish it to
> Whimsy.
> >
> > So, please log in to the Reporter tool via the following URL and begin
> > entering your contributions to this month's report and save them as a
> draft.
> >
> > https://reporter.apache.org/wizard/?activemq
> >
> > As noted above and previously, while logged in to the Reporter tool,
> please
> > DO NOT click the 'Publish to Whimsy' button.
> >
> > Please let me know if you have any questions.
> >
> > Bruce
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > http://bsnyder.org/
Re: [DISCUSS] Migrate from Jira to GitHub Issues
> When users want Jira access, do they use an Apache account, or can it be any account? Folks who have an Apache account (e.g. committers, PMC members, etc.) automatically have access to the ASF Jira instance. > Or are we just creating jira-specific accounts for these users? If you don't have an Apache account and you want to create a Jira, for example, then you must request a Jira account. This is an account specifically for the ASF Jira instance. Lots of websites employ OAuth so that you can, for example, use your Google account or Facebook account to access their services. That's not true of ASF Jira. You must have a specific ASF Jira account. > Do they have / need-to-have an ICLA signed and on-file? No. > It seems to me the real issue at heart here is avoiding spam, and using authenticated users as a means to that end. So, I'm trying to understand whether that's feasible with Apache Jira. As far as I know ASF Infra has _always_ required an account to create Jiras, etc. However, that requirement still hasn't been sufficient to prevent spam - even with a captcha for creating an account. Therefore, the PMC now has to approve Jira account requests. Justin On Wed, Apr 3, 2024 at 11:10 AM Arthur Naseef wrote: > I read through Justin's document up to the section "Why Use GitHub > Issues?" and have questions. > > When users want Jira access, do they use an Apache account, or can it > be any account? Or are we just creating jira-specific accounts for > these users? Do they have / need-to-have an ICLA signed and on-file? > > It seems to me the real issue at heart here is avoiding spam, and > using authenticated users as a means to that end. So, I'm trying to > understand whether that's feasible with Apache Jira. > > Art > > P.S. Nice write-up Justin - thank you! > > On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré > wrote: > > > > Hi Justin > > > > Fantastic work and great summary ! > > > > I do a quick pass, I will do a more detailed read. > > > > Thanks ! > > Regards > > JB > > > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram > wrote: > > > > > > There's been a few threads about this general subject, but most have > > > concentrated on Classic in particular. I think it's worth discussing > > > migration of ActiveMQ as a whole and diving a bit deeper into the > details > > > of why a migration makes (or doesn't make) sense and what the > challenges > > > may be. > > > > > > To this end I've put together this document [1]. I hope it will be of > > > service to the community as we consider this option. > > > > > > > > > Justin > > > > > > [1] > > > > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review > >
Re: [VOTE] Migrate ActiveMQ Classic issues from JIRA to GitHub
I just started a new [DISCUSS] thread related to this. It has a link to my findings. Justin On Thu, Mar 28, 2024 at 2:19 PM Justin Bertram wrote: > I was actually just working on it. I was out a fair bit last week due to > Spring Break so that caused some delay. I'll get it together ASAP. > > > Justin > > On Thu, Mar 28, 2024 at 2:09 PM Matt Pavlovich wrote: > >> Hey Justin- >> >> Checking in.. have you had a chance to collect your findings? >> >> Thanks, >> Matt >> >> > On Mar 18, 2024, at 3:26 PM, Justin Bertram >> wrote: >> > >> > I hope to present it later this week. Thanks for your patience! >> > >> > >> > Justin >> > >> > On Sun, Mar 17, 2024 at 6:16 PM Matt Pavlovich >> wrote: >> > >> >> Hi Justin- >> >> >> >> Sure, when do you plan to share your research? >> >> >> >> Thanks, >> >> Matt >> >> >> >>> On Mar 15, 2024, at 10:22 AM, Justin Bertram >> >> wrote: >> >>> >> >>> -1 >> >>> >> >>> I don't think there's been sufficient discussion of the pros and cons >> to >> >>> make an informed decision. I've done some investigation and testing >> and >> >> I'd >> >>> like a chance to present my findings. This would be a fairly >> significant >> >>> change, and I think it deserves a more detailed review than we've had >> so >> >>> far. >> >>> >> >>> Also, I think migration should be considered for ActiveMQ as a whole >> and >> >>> not just a single component (i.e. Classic). Having multiple different >> >> ways >> >>> to complete the same task in the same project isn't going to be great >> for >> >>> users or contributors. If the change is good for one component then it >> >>> stands to reason that it would be good for all. >> >>> >> >>> >> >>> Justin >> >>> >> >>> On Fri, Mar 15, 2024 at 10:06 AM Matt Pavlovich >> >> wrote: >> >>> >> >>>> All- >> >>>> >> >>>> Kicking off a vote thread for migrating ActiveMQ Classic issues from >> >> JIRA >> >>>> to GitHub. >> >>>> >> >>>> This vote covers: >> >>>> - Migration of ActiveMQ Classic JIRA issues to GitHub >> >>>> - Update Apache ActiveMQ website with links to GitHub issues >> >>>> >> >>>> This vote will be open for at least 72 hours. >> >>>> >> >>>> Thank you, >> >>>> Matt Pavlovich >> >>>> >> >>>> >> >> >> >> >> >>
[DISCUSS] Migrate from Jira to GitHub Issues
There's been a few threads about this general subject, but most have concentrated on Classic in particular. I think it's worth discussing migration of ActiveMQ as a whole and diving a bit deeper into the details of why a migration makes (or doesn't make) sense and what the challenges may be. To this end I've put together this document [1]. I hope it will be of service to the community as we consider this option. Justin [1] https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
Re: [VOTE] Migrate ActiveMQ Classic issues from JIRA to GitHub
I was actually just working on it. I was out a fair bit last week due to Spring Break so that caused some delay. I'll get it together ASAP. Justin On Thu, Mar 28, 2024 at 2:09 PM Matt Pavlovich wrote: > Hey Justin- > > Checking in.. have you had a chance to collect your findings? > > Thanks, > Matt > > > On Mar 18, 2024, at 3:26 PM, Justin Bertram wrote: > > > > I hope to present it later this week. Thanks for your patience! > > > > > > Justin > > > > On Sun, Mar 17, 2024 at 6:16 PM Matt Pavlovich > wrote: > > > >> Hi Justin- > >> > >> Sure, when do you plan to share your research? > >> > >> Thanks, > >> Matt > >> > >>> On Mar 15, 2024, at 10:22 AM, Justin Bertram > >> wrote: > >>> > >>> -1 > >>> > >>> I don't think there's been sufficient discussion of the pros and cons > to > >>> make an informed decision. I've done some investigation and testing and > >> I'd > >>> like a chance to present my findings. This would be a fairly > significant > >>> change, and I think it deserves a more detailed review than we've had > so > >>> far. > >>> > >>> Also, I think migration should be considered for ActiveMQ as a whole > and > >>> not just a single component (i.e. Classic). Having multiple different > >> ways > >>> to complete the same task in the same project isn't going to be great > for > >>> users or contributors. If the change is good for one component then it > >>> stands to reason that it would be good for all. > >>> > >>> > >>> Justin > >>> > >>> On Fri, Mar 15, 2024 at 10:06 AM Matt Pavlovich > >> wrote: > >>> > >>>> All- > >>>> > >>>> Kicking off a vote thread for migrating ActiveMQ Classic issues from > >> JIRA > >>>> to GitHub. > >>>> > >>>> This vote covers: > >>>> - Migration of ActiveMQ Classic JIRA issues to GitHub > >>>> - Update Apache ActiveMQ website with links to GitHub issues > >>>> > >>>> This vote will be open for at least 72 hours. > >>>> > >>>> Thank you, > >>>> Matt Pavlovich > >>>> > >>>> > >> > >> > >
Re: MechanismFinder
I've not dabbled much in this code, but I believe at the very least you can use org.apache.activemq.artemis.protocol.amqp.broker.ProtonProtocolManager#setSaslMechanisms to pass in your own list which will override what's found via the MechanismFinder. Justin On Tue, Mar 26, 2024 at 4:20 PM wrote: > Hello! > > I've run into a bit of a roadblock due to artemis-amqp-protocol's > MechanismFinder. > > I'm working on a library that embeds a broker. As part of this library, > users pass in "authenticators" which are small classes that implement > custom authentication mechanisms. I don't expose any of ActiveMQ's API > anywhere; the library is supposed to be conceptually broker-independent > although ActiveMQ is the only implementation behind it right now. Some > authenticators may require a custom SASL mechanism. > > The only way to get a custom SASL mechanism into ActiveMQ's AMQP > implementation right now is to register a class as a ServiceLoader > service, and hope that the precedence is set highly enough that it > overrides any existing mechanism if there are conflicts. > > The problem with this is that ServiceLoader registration happens "too > early" and is also global state that will affect any broker instance > that happens to be in the same VM: I don't know which SASL mechanisms > should be registered until the user has produced a list of > authenticators at library initialization time, and I don't want one > broker's authenticators to cause conflicting SASL mechanisms to affect > other brokers in the same VM. I don't expect multiple brokers in the > same VM to be a common use case, but I don't think things should quietly > break if someone does try it. > > Only the AMQPConnectionCallback and ProtonProtocolManager use the > MechanismFinder class. Would it be possible to add some method to > explicitly pass in a list of SASL mechanisms, falling back to > MechanismFinder if a list isn't provided? > > I'm a proponent of ServiceLoader in general, but I think this is the > wrong way to use it. Library code (of which I consider > artemis-amqp-protocol) should typically always provide a way to pass in > lists of > services explicitly, or fall back to ServiceLoader. It also makes unit > testing a hell of a lot easier. > > -- > Mark Raynsford | https://www.io7m.com > >
Re: How to add a new authentication mechanism?
In that case you're probably better off implementing your own security manager [1]. ActiveMQ Artemis ships with three implementations [2] which you can use as a reference: - org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager [3] (used by default by the standalone broker) - org.apache.activemq.artemis.spi.core.security.ActiveMQBasicSecurityManager [4] - org.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManagerImpl [5] If you're using org.apache.activemq.artemis.core.server.embedded.EmbeddedActiveMQ to embed the broker you can set the security manager using the setSecurityManager method [6]. Justin [1] https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.java [2] https://activemq.apache.org/components/artemis/documentation/latest/security.html#user-credentials [3] https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java [4] https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQBasicSecurityManager.java [5] https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManagerImpl.java [6] https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/embedded/EmbeddedActiveMQ.java#L72 On Mon, Mar 25, 2024 at 4:13 PM Mark Raynsford wrote: > On 25/03/2024 01:36, Justin Bertram wrote: > > It's simple to use login.config with an embedded broker. You just need to > > set the java.security.auth.login.config system property to the path of > your > > login.config file and it should work. > > > > That's not great, to be honest. I'm essentially building what amounts to > a reusable library that embeds a broker. Although I doubt many people > would be creating multiple broker instances in the same application when > using the library, it would mean that the library would have to set that > system property (which might conflict with something the user has > already set for their own application), and then create a file in the > filesystem that otherwise wouldn't exist, and multiple brokers would > likely step on each other's state. > > Is there no other way to pass in a list of login modules? > > -- > Mark Raynsford | https://www.io7m.com > >
Re: How to add a new authentication mechanism?
It's simple to use login.config with an embedded broker. You just need to set the java.security.auth.login.config system property to the path of your login.config file and it should work. Justin On Sun, Mar 24, 2024 at 4:27 AM Mark Raynsford wrote: > On 24/03/2024 03:21, Justin Bertram wrote: > > ActiveMQ Artemis uses JAAS [1] which uses pluggable "login modules" [2] > > configured via the login.config file in the etc directory of the broker > > instance. We ship a handful of our own login modules which you can peruse > > [3] for pointers on how to implement your own. Documentation is here [4]. > > > > > > Justin > > > > [1] > > > https://docs.oracle.com/en/java/javase/11/security/java-authentication-and-authorization-service-jaas-reference-guide.html > > [2] > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/security/auth/spi/LoginModule.html > > [3] > > > https://github.com/apache/activemq-artemis/tree/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas > > [4] > > > https://activemq.apache.org/components/artemis/documentation/latest/security.html#authentication-authorization > > Thanks! This looks good. > > I'm actually using an embedded broker, so presumably I'll need to do the > registration in some other way than login.config. > > -- > Mark Raynsford | https://www.io7m.com > >
Re: How to add a new authentication mechanism?
ActiveMQ Artemis uses JAAS [1] which uses pluggable "login modules" [2] configured via the login.config file in the etc directory of the broker instance. We ship a handful of our own login modules which you can peruse [3] for pointers on how to implement your own. Documentation is here [4]. Justin [1] https://docs.oracle.com/en/java/javase/11/security/java-authentication-and-authorization-service-jaas-reference-guide.html [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/security/auth/spi/LoginModule.html [3] https://github.com/apache/activemq-artemis/tree/main/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas [4] https://activemq.apache.org/components/artemis/documentation/latest/security.html#authentication-authorization On Sat, Mar 23, 2024 at 7:49 AM Mark Raynsford wrote: > Hello! > > I'm working with a custom authentication mechanism for a few projects. > I'd like to be able to implement that mechanism within ActiveMQ Artemis. > > Is there any documentation on adding new authentication mechanisms? It > seems like I should be able to register a new SASL mechanism somewhere > and then have ActiveMQ call my own code to do the authentication. If > not, is there another method that's better suited than SASL? > > While the new authentication mechanism is documented in a specification, > it's essentially "proprietary" and probably not of general use to others. > > For the morbidly curious: The connecting client forwards the public part > of an Ed448 keypair. The server checks to see if the public key is > registered in its own database. If not, authentication fails. If the > public key _is_ known to the server, the server sends a long random > string. The client signs the long random string, and sends it back. The > server verifies the signature on the long random string (thus seeing if > the client can prove that it owns the private key associated with the > keypair). This is basically analogous to SSH public key authentication. > > -- > Mark Raynsford | https://www.io7m.com > >
Re: [ANNOUNCE] ActiveMQ Artemis 2.33.0 Released
Sorry, Chris. I missed that step. I just sent the result email to close the loop. Justin On Sat, Mar 23, 2024 at 12:21 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Was there a result email sent? I didn't see one, I just see the vote thread > and then the announcement. > > On Sat, Mar 23, 2024 at 12:25 AM Justin Bertram > wrote: > > > I'm pleased to announce the release of ActiveMQ Artemis 2.33.0. > > > > Downloads are now available at: > > https://activemq.apache.org/components/artemis/download/ > > > > For a complete list of updates: > > > > > https://activemq.apache.org/components/artemis/download/release-notes-2.33.0 > > > > I would like to highlight these improvements: > > > > - Support for JSON formatted typed properties on CLI producer command > > - New CLI command pwd for showing directories related to the current > > instance > > - Maven Bill of Materials (BOM) artemis-bom to simplify integration > > - "FirstMessage" API for scheduled messages > > - New "view" and "edit" permissions for management operations > configurable > > via security-settings in broker.xml > > - New sslAutoReload parameter for the embedded web server configured in > > `bootstrap.xml` to detect and automatically reload when SSL stores change > > on disk > > - Performance improvements on mirroring and paging > > - Logging metrics to mitigate the risk of missing WARN or ERROR messages > > in the log. > > - Much improved documentation on network isolation (aka split brain) > > - Pluggable lock manager (aka pluggable quorum voting) out of > > "experimental" status and ready for general use > > > > As usual it contains a handful of bug fixes, dependency upgrades, and > other > > improvements. > > > > Many thanks for all the contributors to this release. > > > > > > Justin > > >
[RESULT] [VOTE] Apache ActiveMQ Artemis 2.33.0
The vote passed with 6 binding votes. The following votes were received: Binding: +1 Justin Bertram +1 Domenico Francesco Bruscino +1 Clebert Suconic +1 Timothy Bish +1 Jean-Baptiste Onofré +1 Christopher Shannon Thank you to everyone who contributed and took the time to review the release candidates and vote. I will add the files to the dist release repo and release the maven staging repo, updating the website once it has had time to sync to the CDN and Maven Central. Justin On Tue, Mar 19, 2024 at 6:12 PM Justin Bertram wrote: > I would like to propose an Apache ActiveMQ Artemis 2.33.0 release. > > Here are some noteworthy updates in 2.33.0: > > - Support for JSON formatted typed properties on CLI producer command > - New CLI command pwd for showing directories related to the current > instance > - Maven Bill of Materials (BOM) artemis-bom to simplify integration > - "FirstMessage" API for scheduled messages > - New "view" and "edit" permissions for management operations > configurable via security-settings in broker.xml > - New sslAutoReload parameter for the embedded web server configured in > `bootstrap.xml` to detect and automatically reload when SSL stores change > on disk > - Performance improvements on mirroring and paging > - Logging metrics to mitigate the risk of missing WARN or ERROR messages > in the log. > - Much improved documentation on network isolation (aka split brain) > - Pluggable lock manager (aka pluggable quorum voting) out of > "experimental" status and ready for general use > > The release notes can be found here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12354184 > > Ths git commit report is here: > > https://activemq.apache.org/components/artemis/download/commit-report-2.33.0 > > Source and binary distributions can be found here: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.33.0/ > > The Maven staging repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1391/ > > If you would like to validate the release: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases > > It is tagged in the git repo as 2.33.0 > > [ ] +1 approve this release > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here's my +1 > > > Justin >
[ANNOUNCE] ActiveMQ Artemis 2.33.0 Released
I'm pleased to announce the release of ActiveMQ Artemis 2.33.0. Downloads are now available at: https://activemq.apache.org/components/artemis/download/ For a complete list of updates: https://activemq.apache.org/components/artemis/download/release-notes-2.33.0 I would like to highlight these improvements: - Support for JSON formatted typed properties on CLI producer command - New CLI command pwd for showing directories related to the current instance - Maven Bill of Materials (BOM) artemis-bom to simplify integration - "FirstMessage" API for scheduled messages - New "view" and "edit" permissions for management operations configurable via security-settings in broker.xml - New sslAutoReload parameter for the embedded web server configured in `bootstrap.xml` to detect and automatically reload when SSL stores change on disk - Performance improvements on mirroring and paging - Logging metrics to mitigate the risk of missing WARN or ERROR messages in the log. - Much improved documentation on network isolation (aka split brain) - Pluggable lock manager (aka pluggable quorum voting) out of "experimental" status and ready for general use As usual it contains a handful of bug fixes, dependency upgrades, and other improvements. Many thanks for all the contributors to this release. Justin
[VOTE] Apache ActiveMQ Artemis 2.33.0
I would like to propose an Apache ActiveMQ Artemis 2.33.0 release. Here are some noteworthy updates in 2.33.0: - Support for JSON formatted typed properties on CLI producer command - New CLI command pwd for showing directories related to the current instance - Maven Bill of Materials (BOM) artemis-bom to simplify integration - "FirstMessage" API for scheduled messages - New "view" and "edit" permissions for management operations configurable via security-settings in broker.xml - New sslAutoReload parameter for the embedded web server configured in `bootstrap.xml` to detect and automatically reload when SSL stores change on disk - Performance improvements on mirroring and paging - Logging metrics to mitigate the risk of missing WARN or ERROR messages in the log. - Much improved documentation on network isolation (aka split brain) - Pluggable lock manager (aka pluggable quorum voting) out of "experimental" status and ready for general use The release notes can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12354184 Ths git commit report is here: https://activemq.apache.org/components/artemis/download/commit-report-2.33.0 Source and binary distributions can be found here: https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.33.0/ The Maven staging repository is here: https://repository.apache.org/content/repositories/orgapacheactivemq-1391/ If you would like to validate the release: https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases It is tagged in the git repo as 2.33.0 [ ] +1 approve this release [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here's my +1 Justin
Re: Upgrading the Artemis Console
Good grief. I'll get that one removed. I just created https://github.com/apache/activemq-artemis-console-plugin.git. Please use that one instead. Thanks for the heads up! Justin On Tue, Mar 19, 2024 at 10:23 AM Timothy Bish wrote: > On 3/19/24 11:01, Justin Bertram wrote: > > Done - > https://github.com/apache/activemq-activemq-artemis-console-plugin > > > Looks like you included 'activemq' in the name when creating the repo so > now you have two activemq's in the new repo name, likely should get that > fixed. > > > > Justin > > > > On Tue, Mar 19, 2024 at 9:55 AM Andy Taylor > wrote: > > > >> Correct > >> > >> On Tue, 19 Mar 2024, 14:29 Justin Bertram, wrote: > >> > >>> Just to confirm...The repo name should be > >>> "activemq-artemis-console-plugin", right? > >>> > >>> > >>> Justin > >>> > >>> On Tue, Mar 19, 2024 at 9:22 AM Andy Taylor > >>> wrote: > >>> > >>>> turns out I don't have permissions to create a repo, could someone > from > >>> the > >>>> PMC do this for me? > >>>> > >>>> On Tue, 19 Mar 2024 at 09:27, Andy Taylor > >>> wrote: > >>>>> I will go ahead and request the new repo today > >>>>> > >>>>> On Mon, 18 Mar 2024 at 18:39, Timothy Bish > >>> wrote: > >>>>>> On 3/18/24 13:33, Andy Taylor wrote: > >>>>>>> so I am open to names, how about artemis-console-plugin v1.0.0 > >>>>>> +1 > >>>>>> > >>>>>> > >>>>>>> On Mon, 18 Mar 2024 at 17:24, Clebert Suconic < > >>>>>> clebert.suco...@gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> +1 on activemq-artemis-console-plugin > >>>>>>>> > >>>>>>>> > >>>>>>>> As Robbie said, you will need different versions for it. I feel > >>> like > >>>>>>>> it would be easier to use a different name... but I don't mind > >> what > >>>>>>>> you have to do. Whatever makes it easier to be implemented. > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell < > >>>>>> robbie.gemm...@gmail.com> > >>>>>>>> wrote: > >>>>>>>>> On the module name, if it stays the same then consideration > >> would > >>>> also > >>>>>>>>> need to be given to the version. It would need to be higher than > >>>>>>>>> before to keep using the same name, but using a broker version > >>> isnt > >>>>>>>>> necessarily that obvious if we dont expect to release it on the > >>> same > >>>>>>>>> schedule as the broker. > >>>>>>>>> > >>>>>>>>> On Mon, 18 Mar 2024 at 16:46, Andy Taylor < > >> andy.tayl...@gmail.com > >>>>>>>> wrote: > >>>>>>>>>> +1 for avtivemq-artemis-console-plugin but I think we should > >>> keep > >>>>>> the > >>>>>>>>>> artifact name as it is now for consistency, i.e. artemis-plugin > >>>>>>>>>> > >>>>>>>>>> On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell < > >>>>>> robbie.gemm...@gmail.com > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> We should discuss the name then someone can create it via > >>>>>>>>>>> https://selfserve.apache.org > >>>>>>>>>>> > >>>>>>>>>>> It would be something of the form activemq-artemis- for > >>>>>>>>>>> consistency. Regarding , what is actually going in it, a > >>>>>> console > >>>>>>>>>>> 'plugin' ? > >>>>>>>>>>> > >>>>>>>>>>> So perhaps activemq-artemis-console-plugin ? > >>>>>>>>>>> > >>>>>>>>>>> O
Re: Upgrading the Artemis Console
Done - https://github.com/apache/activemq-activemq-artemis-console-plugin Justin On Tue, Mar 19, 2024 at 9:55 AM Andy Taylor wrote: > Correct > > On Tue, 19 Mar 2024, 14:29 Justin Bertram, wrote: > > > Just to confirm...The repo name should be > > "activemq-artemis-console-plugin", right? > > > > > > Justin > > > > On Tue, Mar 19, 2024 at 9:22 AM Andy Taylor > > wrote: > > > > > turns out I don't have permissions to create a repo, could someone from > > the > > > PMC do this for me? > > > > > > On Tue, 19 Mar 2024 at 09:27, Andy Taylor > > wrote: > > > > > > > I will go ahead and request the new repo today > > > > > > > > On Mon, 18 Mar 2024 at 18:39, Timothy Bish > > wrote: > > > > > > > >> On 3/18/24 13:33, Andy Taylor wrote: > > > >> > so I am open to names, how about artemis-console-plugin v1.0.0 > > > >> > > > >> +1 > > > >> > > > >> > > > >> > On Mon, 18 Mar 2024 at 17:24, Clebert Suconic < > > > >> clebert.suco...@gmail.com> > > > >> > wrote: > > > >> > > > > >> >> +1 on activemq-artemis-console-plugin > > > >> >> > > > >> >> > > > >> >> As Robbie said, you will need different versions for it. I feel > > like > > > >> >> it would be easier to use a different name... but I don't mind > what > > > >> >> you have to do. Whatever makes it easier to be implemented. > > > >> >> > > > >> >> > > > >> >> On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell < > > > >> robbie.gemm...@gmail.com> > > > >> >> wrote: > > > >> >>> On the module name, if it stays the same then consideration > would > > > also > > > >> >>> need to be given to the version. It would need to be higher than > > > >> >>> before to keep using the same name, but using a broker version > > isnt > > > >> >>> necessarily that obvious if we dont expect to release it on the > > same > > > >> >>> schedule as the broker. > > > >> >>> > > > >> >>> On Mon, 18 Mar 2024 at 16:46, Andy Taylor < > andy.tayl...@gmail.com > > > > > > >> >> wrote: > > > >> >>>> +1 for avtivemq-artemis-console-plugin but I think we should > > keep > > > >> the > > > >> >>>> artifact name as it is now for consistency, i.e. artemis-plugin > > > >> >>>> > > > >> >>>> On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell < > > > >> robbie.gemm...@gmail.com > > > >> >>>> wrote: > > > >> >>>> > > > >> >>>>> We should discuss the name then someone can create it via > > > >> >>>>> https://selfserve.apache.org > > > >> >>>>> > > > >> >>>>> It would be something of the form activemq-artemis- for > > > >> >>>>> consistency. Regarding , what is actually going in it, a > > > >> console > > > >> >>>>> 'plugin' ? > > > >> >>>>> > > > >> >>>>> So perhaps activemq-artemis-console-plugin ? > > > >> >>>>> > > > >> >>>>> On Mon, 18 Mar 2024 at 07:46, Andy Taylor < > > andy.tayl...@gmail.com > > > > > > > >> >> wrote: > > > >> >>>>>> Lets go with a separate repo then, @clebert or anyone, can > you > > > >> >> create me > > > >> >>>>> a > > > >> >>>>>> new repo or talk me thru how to do it. What shall we call > this > > > new > > > >> >>>>>> component/repo, considering we will still have an > > artemis-console > > > >> >> module > > > >> >>>>> in > > > >> >>>>>> the artemis repo? > > > >> >>>>>> > > > >> >>>>>> Clebert, I will add this new fields in your PR to the new > > console > > > >> >> as >
Re: Upgrading the Artemis Console
Just to confirm...The repo name should be "activemq-artemis-console-plugin", right? Justin On Tue, Mar 19, 2024 at 9:22 AM Andy Taylor wrote: > turns out I don't have permissions to create a repo, could someone from the > PMC do this for me? > > On Tue, 19 Mar 2024 at 09:27, Andy Taylor wrote: > > > I will go ahead and request the new repo today > > > > On Mon, 18 Mar 2024 at 18:39, Timothy Bish wrote: > > > >> On 3/18/24 13:33, Andy Taylor wrote: > >> > so I am open to names, how about artemis-console-plugin v1.0.0 > >> > >> +1 > >> > >> > >> > On Mon, 18 Mar 2024 at 17:24, Clebert Suconic < > >> clebert.suco...@gmail.com> > >> > wrote: > >> > > >> >> +1 on activemq-artemis-console-plugin > >> >> > >> >> > >> >> As Robbie said, you will need different versions for it. I feel like > >> >> it would be easier to use a different name... but I don't mind what > >> >> you have to do. Whatever makes it easier to be implemented. > >> >> > >> >> > >> >> On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell < > >> robbie.gemm...@gmail.com> > >> >> wrote: > >> >>> On the module name, if it stays the same then consideration would > also > >> >>> need to be given to the version. It would need to be higher than > >> >>> before to keep using the same name, but using a broker version isnt > >> >>> necessarily that obvious if we dont expect to release it on the same > >> >>> schedule as the broker. > >> >>> > >> >>> On Mon, 18 Mar 2024 at 16:46, Andy Taylor > >> >> wrote: > >> >>>> +1 for avtivemq-artemis-console-plugin but I think we should keep > >> the > >> >>>> artifact name as it is now for consistency, i.e. artemis-plugin > >> >>>> > >> >>>> On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell < > >> robbie.gemm...@gmail.com > >> >>>> wrote: > >> >>>> > >> >>>>> We should discuss the name then someone can create it via > >> >>>>> https://selfserve.apache.org > >> >>>>> > >> >>>>> It would be something of the form activemq-artemis- for > >> >>>>> consistency. Regarding , what is actually going in it, a > >> console > >> >>>>> 'plugin' ? > >> >>>>> > >> >>>>> So perhaps activemq-artemis-console-plugin ? > >> >>>>> > >> >>>>> On Mon, 18 Mar 2024 at 07:46, Andy Taylor > > >> >> wrote: > >> >>>>>> Lets go with a separate repo then, @clebert or anyone, can you > >> >> create me > >> >>>>> a > >> >>>>>> new repo or talk me thru how to do it. What shall we call this > new > >> >>>>>> component/repo, considering we will still have an artemis-console > >> >> module > >> >>>>> in > >> >>>>>> the artemis repo? > >> >>>>>> > >> >>>>>> Clebert, I will add this new fields in your PR to the new console > >> >> as > >> >>>>> well. > >> >>>>>> Andy > >> >>>>>> > >> >>>>>> On Fri, 15 Mar 2024 at 19:03, Clebert Suconic < > >> >> clebert.suco...@gmail.com > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>>> I think we have a consensus on a separate repo. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> @Andy: me an Anton, we wre adding a field for internal queues > >> >> in the > >> >>>>> admin > >> >>>>>>> console. If you could make sure we keep that on the new one > >> >> please ? > >> >>>>> Or > >> >>>>>>> let us know how to adjust it? > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> https://github.com/apache/activemq-artemis/pull/4856 > >> >>>>>>> > >> >>>>>>> > >>
Re: [VOTE] Migrate ActiveMQ Classic issues from JIRA to GitHub
I hope to present it later this week. Thanks for your patience! Justin On Sun, Mar 17, 2024 at 6:16 PM Matt Pavlovich wrote: > Hi Justin- > > Sure, when do you plan to share your research? > > Thanks, > Matt > > > On Mar 15, 2024, at 10:22 AM, Justin Bertram > wrote: > > > > -1 > > > > I don't think there's been sufficient discussion of the pros and cons to > > make an informed decision. I've done some investigation and testing and > I'd > > like a chance to present my findings. This would be a fairly significant > > change, and I think it deserves a more detailed review than we've had so > > far. > > > > Also, I think migration should be considered for ActiveMQ as a whole and > > not just a single component (i.e. Classic). Having multiple different > ways > > to complete the same task in the same project isn't going to be great for > > users or contributors. If the change is good for one component then it > > stands to reason that it would be good for all. > > > > > > Justin > > > > On Fri, Mar 15, 2024 at 10:06 AM Matt Pavlovich > wrote: > > > >> All- > >> > >> Kicking off a vote thread for migrating ActiveMQ Classic issues from > JIRA > >> to GitHub. > >> > >> This vote covers: > >> - Migration of ActiveMQ Classic JIRA issues to GitHub > >> - Update Apache ActiveMQ website with links to GitHub issues > >> > >> This vote will be open for at least 72 hours. > >> > >> Thank you, > >> Matt Pavlovich > >> > >> > >
Re: HEADS-UP Artemis 2.33.0 Release
Sure thing. I'll do it tomorrow. Justin On Mon, Mar 18, 2024 at 3:13 PM Clebert Suconic wrote: > I will not be able to actually do this release. > > I miscalculated the time for the VOTE versus when I'm expected to be away. > > > if someone else could do this release? (Justin Bertram? or anyone else > volunteering?) > > On Wed, Mar 13, 2024 at 10:29 AM Clebert Suconic > wrote: > > > > I would like to try releasing Artemis 2.33.0 on Monday, March, 18... > > > > If I miss this windo I won't be able to release that week as I will > > have vacations the week after.. .on which case I would like someone > > else to release or wait when I am back. > > > > > > Having said that, I would like to have everything ready before then... > > Please ping me on github with a tag-comment on anything you want to > > include.. or feel free to respond here with links to issues we should > > fix before releasing. (or do both if you want :) ) > > > > > > > > thank you. > > > > -- > > Clebert Suconic > > > > -- > Clebert Suconic > >
Re: [VOTE] Migrate ActiveMQ Classic issues from JIRA to GitHub
-1 I don't think there's been sufficient discussion of the pros and cons to make an informed decision. I've done some investigation and testing and I'd like a chance to present my findings. This would be a fairly significant change, and I think it deserves a more detailed review than we've had so far. Also, I think migration should be considered for ActiveMQ as a whole and not just a single component (i.e. Classic). Having multiple different ways to complete the same task in the same project isn't going to be great for users or contributors. If the change is good for one component then it stands to reason that it would be good for all. Justin On Fri, Mar 15, 2024 at 10:06 AM Matt Pavlovich wrote: > All- > > Kicking off a vote thread for migrating ActiveMQ Classic issues from JIRA > to GitHub. > > This vote covers: > - Migration of ActiveMQ Classic JIRA issues to GitHub > - Update Apache ActiveMQ website with links to GitHub issues > > This vote will be open for at least 72 hours. > > Thank you, > Matt Pavlovich > >
Re: Upgrading the Artemis Console
+1 for a separate repo Justin On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor wrote: > Clebert, I think it will be weeks rather than days so I would just release > when you are ready. > > Robbie, I think for now a separate repo is my preferred solution, the > console can actually be run outside of embedded artemis so development is > easy. Can someone create a new repo? > > On Wed, 13 Mar 2024 at 17:45, Clebert Suconic > wrote: > > > If it was a matter of 1 day to include it I would prefer to wait for it. > > Other than that then I’m releasing on Monday. > > > > > > On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell > > > wrote: > > > > > I'd say the answer to 'Wait for to do a release?' is usually no > > > unless its about a blocking bug/regression or there's really nothing > > > else important ready to go. This definitely isnt that and also isnt > > > ready yet while other stuff is, so seems a clear no to me. > > > > > > On Wed, 13 Mar 2024 at 16:58, Clebert Suconic < > clebert.suco...@gmail.com > > > > > > wrote: > > > > > > > > Should I wait for the 2.33 release ? > > > > > > > > > > > > See my other thread about the heads up. > > > > > > > > > > > > Or you think this may take a lot longer ? > > > > > > > > On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor > > > wrote: > > > > > > > > > The current Artemis console is based on HawtIO 1 which itself is > > > written > > > > > using Bootstrap. Bootstrap is old and no longer maintained so > HawtIO > > > (v3/4) > > > > > has moved to use React and Patternfly and is also written in > > > Typescript. > > > > > > > > > > I have been working in the background over the last several months > to > > > > > upgrade the console to hawtIO 4, this work can be found here > > > > > < > > > https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng > >. > > > > > This is still a WIP but is close to completion, I basically have to > > > finish > > > > > off some branding, fix the console tests and implement an upgrade > > > feature. > > > > > A couple of things to note: > > > > > > > > > > > > > > >- I have separated out the JMX tree and its tabs from the tabs > > that > > > are > > > > >not related to the tree selection. I always found this a bit > > > strange so > > > > > now > > > > >there are 2 tabs Artemis and Artemis JMX, the latter uses the > JMX > > > tree > > > > > as > > > > >before. It is possible however to do anything in the Artemis tab > > > that > > > > > you > > > > >can do in the JMX tab, view attributes and operations for > > instance. > > > > > There > > > > >is an issue currently where if there are thousands of address or > > > queues > > > > >then performance becomes an issue. this is because the whole JMX > > > tree is > > > > >loaded into memory and this can cause even the broker to fall > > over. > > > My > > > > > plan > > > > >at some point is to allow disabling the JMX view and to lazy > load > > in > > > > > MBeans > > > > >as and when needed, this is a task for further down the road > tho. > > > > >- The console is built using yarn and is incredibly slow to > build, > > > in > > > > >fact it takes longer than it takes to build the rest of Artemis. > > It > > > may > > > > > be > > > > >better to have the new console in its own repository, release it > > > > >independently and just consume it in Artemis. This means some > > extra > > > work > > > > >for a release but once the console becomes stable it shouldn't > be > > > too > > > > > much > > > > >work. I will however let the community decide what is the best > > > approach. > > > > > > > > > > > > > > > There are still a few issues I know of, the Attributes tab seems to > > > delay > > > > > loading and the broker topology diagram is incomplete but feel free > > to > > > > > suggest any improvements or buglets you come across on this thread. > > > > > Hopefully I can tie up the loose ends soon and raise a PR in the > not > > > too > > > > > distant future. > > > > > > > > > > Andy > > > > > > > > > > >
Re: ActiveMQ Artemis Core - string encoding question
I'm not 100%, but I believe the problem is that the unpooled buffer is
self-expanding and the pooled buffer is not. The JavaDoc for
io.netty.buffer.Unpooled#buffer() states:
> Creates a new big-endian Java heap buffer with reasonably small initial
capacity, which expands its capacity boundlessly on demand.
If you size the pooled buffer correctly (>= 33) the failing tests will
succeed.
Justin
On Sat, Mar 2, 2024 at 6:12 PM Havret wrote:
> I'm including one more failing tests:
>
>@Test
>public void encodeAndDecodeMediumSizeStringOfMoreThan26Chars() {
> String string = "60v4MKNelDuNDUHn8itGjok2HN0";
> ActiveMQBuffer pooledBuffer = ActiveMQBuffers.pooledBuffer(21);
> pooledBuffer.writeString(string);
>
> var array = pooledBuffer.toByteBuffer().array();
> ActiveMQBuffer activeMQBuffer = ActiveMQBuffers.wrappedBuffer(array);
>
> String decoded = activeMQBuffer.readString();
>
> Assert.assertEquals(string, decoded);
>}
>
> org.junit.ComparisonFailure:
> Expected :60v4MKNelDuNDUHn8itGjok2HN0
> Actual :���
>
> On Sun, Mar 3, 2024 at 12:44 AM Havret wrote:
>
> > Hi,
> >
> > I've recently started working on the dotnet Artemis Client that's going
> to
> > use Core protocol. During my work on the binary encoder, I've hit a weird
> > issue. Everything works fine when I encode strings up to 26 characters.
> > But, for strings longer than 26 characters, the binary layout just goes
> > haywire—there's this huge 8k bytes gap from where the last data was
> > encoded, and I can't figure out why.
> >
> > I managed to boil it down to 2 simple test cases you can find here:
> > https://gist.github.com/Havret/486a5acc339c67cdc11eccc33e54b178. The
> > unpooledBuffer behaves as expected, just like in my dotnet setup, but the
> > pooledBuffer acts up strangely. Is this some bug in the Artemis core
> > encoding, or am I missing something obvious?
> >
> > Thanks for any light you can shed on this,
> > Krzysztof
> >
> >
> >
>
Re: ActiveMQ plugin to Artemis migration
I think your best bet is probably to implement a custom security manager that wraps the existing JAAS security manager and intercepts operations and injects data into and pulls data out of the user's Subject. The general wrapping functionality is demonstrated in this example [1]. There is no 1-to-1 mapping for plugins between Classic and Artemis. They are simply too different architecturally. That said, I believe most folks have been able to migrate with a bit of reimplementation and/or rethinking their approach. I'm not sure what you mean that you can't see a way to prevent a client from creating arbitrary queues. There's a whole chapter [2] in the user manual dedicated to security configuration specifically including role-base authorization. There are also a couple of security related examples in the examples repo. Justin [1] https://github.com/apache/activemq-artemis-examples/tree/main/examples/features/standard/security-manager [2] https://activemq.apache.org/components/artemis/documentation/latest/security.html#authentication-authorization On Fri, Feb 16, 2024 at 6:46 AM Jędrzej Dudkiewicz < jedrzej.dudkiew...@gmail.com> wrote: > Hello, > > more than year ago I wrote to this group with the same problem: > > [1] https://www.mail-archive.com/dev@activemq.apache.org/msg68723.html > > I answered questions asked (I think in details) here: > > [2] https://www.mail-archive.com/dev@activemq.apache.org/msg68726.html > > I never got an answer and the problem was left (on my side) for later, > since ActiveMQ is still being developed, but it feels like it may not be > the case in the future, so I don't want to postpone migration. > > I'd like to ask if anything has changed in the broker (Artemis) since I > asked my question above. Or if there is some other way to solve (or > workaround) the main problems i had (quoting from [2]): > > 1. I can't see a way to attach my own data to client's session and the > only way to do it seems to write JAAS plugin/login module. > 2. I can't see a way to prevent client from creating arbitrary queues. > > For details as to why those two are the problems, please refer to [2] > above. > > Thanks, > -- > Jędrzej Dudkiewicz > > I really hate this damn machine, I wish that they would sell it. > It never does just what I want, but only what I tell it. >
Re: Need help connecting to broker using proxy
What kind of proxy are you trying to use?
Also, in the future please direct questions like this to the ActiveMQ
*users* mailing list [1]. This is the dev list for folks working directly
on an ActiveMQ code-base.
Justin
[1] https://activemq.apache.org/contact
On Sat, Jan 6, 2024 at 11:30 AM Sunil Kumar wrote:
> Hi,
>
> i am working on ActiveMQ using c#. I need help in setting the proxy while
> connecting to the broker using ConnectionFactory
>
> IConnectionFactory factory = new
> ConnectionFactory("ssl://mybrokerurl:4040");
> _connection = factory.CreateConnection(_userName, _password);
> _connection.Start();
> _session = _connection.CreateSession();
>
> I get this exception at line 2: Error connecting to mybrokerurl:4040.
> InnerException: Unknown error (0xfffe)
>
> I didn't find a way to set proxy. Please help
>
> Thanks,
> Sunil
>
Re: JMS API with client acknowledgement issue
FYI - the fix for this issue has been merged. It will be available in
ActiveMQ Artemis 2.32.0.
Thanks again for the report!
Justin
On Thu, Nov 30, 2023 at 11:46 AM Justin Bertram wrote:
> I've created ARTEMIS-4520 [1] to deal with this. Thanks for reporting the
> issue!
>
>
> Justin
>
> [1] https://issues.apache.org/jira/browse/ARTEMIS-4520
>
> On Wed, Nov 29, 2023 at 4:08 AM Андрей wrote:
>
>> Hi Team,
>>
>> I am currently using "artemis-jakarta-client" 2.31.2 version
>>
>> I've stumbled into an issue with client acknowledge mode when using JMS
>> API. Here's an example:
>>
>>
>> try (var factory = new ActiveMQConnectionFactory("> try (var ctx = factory.createContext("", "",
>> JMSContext.CLIENT_ACKNOWLEDGE)) {
>> var destination = ctx.createQueue("");
>> try (var consumer = ctx.createConsumer(destination)) {
>> var message1 = consumer.receive(10); // suppose
>> this call returns real message
>> var message2 = consumer.receive(10); // suppose
>> this call times out, so NULL is returned
>> ctx.acknowledge(); // I'm expecting that message1 gets
>> acknowledged here, but it's not happening
>>
>> /*
>> Do something here
>> */
>>
>> }
>> }
>> }
>>
>> The reason for ack not working is that the implementation of
>> "consumer.receive" method stores the latest returned value in JMSContext
>> for future usage in its "acknowledge" method.
>> This happens regardless if the value is null or not. So in case latest
>> call
>> returns null, all the previous messages get lost and never acked.
>>
>> This seem like a defect. Am I right?
>>
>> Thanks in advance
>>
>
Re: JMS API with client acknowledgement issue
I've created ARTEMIS-4520 [1] to deal with this. Thanks for reporting the
issue!
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-4520
On Wed, Nov 29, 2023 at 4:08 AM Андрей wrote:
> Hi Team,
>
> I am currently using "artemis-jakarta-client" 2.31.2 version
>
> I've stumbled into an issue with client acknowledge mode when using JMS
> API. Here's an example:
>
>
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose
> this call returns real message
> var message2 = consumer.receive(10); // suppose
> this call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
>
> /*
> Do something here
> */
>
> }
> }
> }
>
> The reason for ack not working is that the implementation of
> "consumer.receive" method stores the latest returned value in JMSContext
> for future usage in its "acknowledge" method.
> This happens regardless if the value is null or not. So in case latest call
> returns null, all the previous messages get lost and never acked.
>
> This seem like a defect. Am I right?
>
> Thanks in advance
>
Re: JMS API with client acknowledgement issue
Tim, I think those are fair points. Ultimately I think the JavaDoc is
relatively ambiguous, although I tend to favor your interpretation.
What does the Qpid JMS client do in this case?
BTW, I looked through the Jakarta Messaging TCK source code and I don't see
where this specific use-case is exercised.
Justin
On Wed, Nov 29, 2023 at 3:58 PM Timothy Bish wrote:
> On 11/29/23 16:15, Justin Bertram wrote:
> > It's not clear to me that this is a defect. The JavaDoc for
> > JMSContext.acknowledge() [1] says (in part):
> >
> >> This method has identical behaviour to the acknowledge method on
> Message.
> > A client may individually acknowledge each message as it is consumed, or
> it
> > may choose to acknowledge messages as an application-defined group. In
> both
> > cases it makes no difference which of these two methods is used.
> >
> > If receive() returns a null Message Object you can't invoke acknowledge
> on
> > it. Therefore, whether you use JMSContext.acknowledge() or
> > Message.acknowledge() the behavior will be identical - no message will be
> > acknowledged.
> >
> > Also, it's worth noting that messages which are not acknowledged will not
> > be lost. In most cases they will be redelivered or in some cases may be
> > sent to a dead-letter address.
>
> I believe you have skipped over the most important part of the API docs
> for that method which is the first sentence which states:
>
> "Acknowledges all messages consumed by the JMSContext's session."
>
> That would imply it works on the session level regardless of any
> successful (or not) calls to receive (or receiveBody which don't return
> actual message objects) as it is meant to work against "all message
> consumed by the JMSContext's session", not at the individual message
> level which I'd guess is indeed why it was added to the "Simplified API"
> as this would provide the entry point for group acknowledge behavior
> described in the text.
>
> A previously read message from the 'receive' API is in fact a consumed
> message within the session regardless of whether the most recent call
> returned a message.
>
>
> >
> > Justin
> >
> > [1]
> >
> https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#acknowledge--
> >
> > On Wed, Nov 29, 2023 at 4:08 AM Андрей wrote:
> >
> >> Hi Team,
> >>
> >> I am currently using "artemis-jakarta-client" 2.31.2 version
> >>
> >> I've stumbled into an issue with client acknowledge mode when using JMS
> >> API. Here's an example:
> >>
> >>
> >> try (var factory = new
> ActiveMQConnectionFactory(" >> try (var ctx = factory.createContext("",
> "",
> >> JMSContext.CLIENT_ACKNOWLEDGE)) {
> >> var destination = ctx.createQueue("");
> >> try (var consumer = ctx.createConsumer(destination)) {
> >> var message1 = consumer.receive(10); // suppose
> >> this call returns real message
> >> var message2 = consumer.receive(10); // suppose
> >> this call times out, so NULL is returned
> >> ctx.acknowledge(); // I'm expecting that message1
> gets
> >> acknowledged here, but it's not happening
> >>
> >> /*
> >> Do something here
> >> */
> >>
> >> }
> >> }
> >> }
> >>
> >> The reason for ack not working is that the implementation of
> >> "consumer.receive" method stores the latest returned value in JMSContext
> >> for future usage in its "acknowledge" method.
> >> This happens regardless if the value is null or not. So in case latest
> call
> >> returns null, all the previous messages get lost and never acked.
> >>
> >> This seem like a defect. Am I right?
> >>
> >> Thanks in advance
> >>
>
> --
> Tim Bish
>
>
Re: JMS API with client acknowledgement issue
It's not clear to me that this is a defect. The JavaDoc for
JMSContext.acknowledge() [1] says (in part):
> This method has identical behaviour to the acknowledge method on Message.
A client may individually acknowledge each message as it is consumed, or it
may choose to acknowledge messages as an application-defined group. In both
cases it makes no difference which of these two methods is used.
If receive() returns a null Message Object you can't invoke acknowledge on
it. Therefore, whether you use JMSContext.acknowledge() or
Message.acknowledge() the behavior will be identical - no message will be
acknowledged.
Also, it's worth noting that messages which are not acknowledged will not
be lost. In most cases they will be redelivered or in some cases may be
sent to a dead-letter address.
Justin
[1]
https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#acknowledge--
On Wed, Nov 29, 2023 at 4:08 AM Андрей wrote:
> Hi Team,
>
> I am currently using "artemis-jakarta-client" 2.31.2 version
>
> I've stumbled into an issue with client acknowledge mode when using JMS
> API. Here's an example:
>
>
> try (var factory = new ActiveMQConnectionFactory(" try (var ctx = factory.createContext("", "",
> JMSContext.CLIENT_ACKNOWLEDGE)) {
> var destination = ctx.createQueue("");
> try (var consumer = ctx.createConsumer(destination)) {
> var message1 = consumer.receive(10); // suppose
> this call returns real message
> var message2 = consumer.receive(10); // suppose
> this call times out, so NULL is returned
> ctx.acknowledge(); // I'm expecting that message1 gets
> acknowledged here, but it's not happening
>
> /*
> Do something here
> */
>
> }
> }
> }
>
> The reason for ack not working is that the implementation of
> "consumer.receive" method stores the latest returned value in JMSContext
> for future usage in its "acknowledge" method.
> This happens regardless if the value is null or not. So in case latest call
> returns null, all the previous messages get lost and never acked.
>
> This seem like a defect. Am I right?
>
> Thanks in advance
>
Re: activeMQ compatibility with jdk and wildfly version
As Clebert noted, WildFly *doesn't ship* any of the libraries affected by CVE-2023-46604 (i.e. activemq-client.jar & activemq-openwire-legacy.jar) so it's not vulnerable unless you've manually configured support for OpenWire and added such libraries yourself. If that's the case then you can simply upgrade them to the corresponding minor version with the fix. Justin On Fri, Nov 10, 2023 at 12:59 AM Bhargav Budida wrote: > Thanks for your responses. > > We are currently using *JDK 1.8 *and we understand the latest supported > activeMQ-artemis version is 2.19.1 > Actually, we can't upgrade the JDK 1.8 version immediately due to some > backward compatibility issues. > However, looking at the criticality of the vulnerability *CVE-2023-46604*, > we are eagerly looking for a solution keeping JDK8 and related compatible > activeMQ-artemis version 2.19.x > So do you have a fix with 2.19.x version? if not, could you please let us > know the plan to fix the mentioned CVE in 2.19.x version. > > > > On Fri, Nov 10, 2023 at 9:04 AM Clebert Suconic > > wrote: > > > The Artemis in wildfly is not affected by the CVE as openwire is not > > deployed in openwire. > > > > > > Also 2.31 requires jdk 11 but I think it’s a worth choice as there are > many > > fixes in the broker. > > > > On Thu, Nov 9, 2023 at 9:40 AM Bhargav Budida > > wrote: > > > > > Hi Team, > > > > > > This is regarding a recent vulnerability > > > CVE-2023-46604 > > > I am currently using *activeMQ-artemis 2.16.0*, (Jboss) *Wildfly 24.0.0 > > > *and > > > *JDK 1.8*. > > > > > > The latest version of activeMQ-artemis 2.31.2 is not supported by > jdk1.8. > > > So I need your assistance with the below queries > > > 1. Will activeMQ artemis 2.31.2 is compatible with JDK 11 + Wildfly > > > 24.0.0.final or not ? > > > 2. Are there any configurations required to work with the latest > artemis > > > 2.31.2 version, so that it could be compatible with my current server > > > (Wildfly 24.0.0) version > > > 3. As per the mitigation plan over CVE we need to upgrade to 2.31.2 > > version > > > which is compatible with JDK 11, similar to this do we have the fix in > > > artemis 2.19.x version? as it is compatible with JDK 8. > > > > > > Please consider this a priority and share your thoughts ASAP. > > > Thanks in advance > > > > > > -- > > > Thanks & Regards > > > Bhargav > > > 9860584899 > > > > > > > > -- > Thanks & Regards > Bhargav > 9860584899 >
Re: activeMQ compatibility with jdk and wildfly version
> Will activeMQ artemis 2.31.2 is compatible with JDK 11 and Wildfly 24.0.0.final or not ? ActiveMQ Artemis 2.31.2 is compatible with JDK 11. I don't know if ActiveMQ Artemis 2.31.2 is compatible with WildFly 24.0.0.Final. You'd have to ask the WildFly community about that one. > I don't want to upgrade my wildfly version, so are there any configurations required to work with latest artemis version You'd have to ask the WildFly community about that one as well. In the future please direct questions like this to the ActiveMQ *users* mailing list [1]. The dev list is for developers working directly on one of the ActiveMQ code-bases. Justin [1] https://activemq.apache.org/contact On Wed, Nov 8, 2023 at 11:18 AM Bhargav Budida wrote: > Hi Team, > > I am currently using activeMQ-artemis 2.16.0 version , my wildfly version > is 24.0.0 and jdk is 1.8. > > latest versions of activeMQ 2.31.2 is not supported by jdk1.8. > So i need below info required to upgrade > 1. Will activeMQ artemis 2.31.2 is compatible with JDK 11 and Wildfly > 24.0.0.final or not ? > 2. I don't want to upgrade my wildfly version, so are there any > configurations required to work with latest artemis version > > Thanks in advance > > -- > Thanks & Regards > Bhargav > 9860584899 >
Re: Impact of CVE-2023-46604 on activemq-client
After some additional internal discussion we'll be updating the description of the CVE as well as the details on the ActiveMQ website to revise our guidance and make this potential exploit more clear. Thanks for following up! Justin On Tue, Nov 7, 2023 at 4:07 AM Colm O hEigeartaigh wrote: > Thanks JB. What's to stop a malicious broker trying to recreate the > vulnerability then by sending a crafted message to a client? > > Colm. > > On Mon, Nov 6, 2023 at 2:53 PM Jean-Baptiste Onofré > wrote: > > > > Hi Colm > > > > It's on the broker side, not on the client side. However, the change > > is also on client side as it's on the openwire marshalling (shared > > between the client and the broker). > > > > Regards > > JB > > > > On Mon, Nov 6, 2023 at 3:28 PM Colm O hEigeartaigh > wrote: > > > > > > Hi, > > > > > > Security vendors (e.g. > > > https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHEACTIVEMQ-6039483) are > > > flagging CVE-2023-46604 against activemq-client (I guess by looking at > > > the changes to activemq-client > > > > https://github.com/apache/activemq/commit/9905e2a5bf9862a049f94ce0a2465b0c7ad52436 > ). > > > However the explanation on > > > https://activemq.apache.org/news/cve-2023-46604 only mentions that the > > > broker as being vulnerable " The vulnerability may allow a remote > > > attacker with network access to a broker to run arbitrary shell > > > commands "... > > > > > > Is a client of ActiveMQ vulnerable to this CVE if for example it > > > parses a malicious message from the broker? Or is it indeed only the > > > broker who is vulnerable? > > > > > > Thanks, > > > > > > Colm. > >
Re: [VOTE] Release Apache ActiveMQ Artemis 2.31.2
+1 Justin On Fri, Oct 27, 2023 at 6:27 AM Robbie Gemmell wrote: > Hi folks, > > I would like to propose an Apache ActiveMQ Artemis 2.31.2 release. > > This addresses a defect introduced in the recent 2.31.1 release. > > The release notes can be found here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353776 > > Source and binary distributions can be found here: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.2/ > > The Maven staging repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1379 > > If you would like to validate the release: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases > > It is tagged in the git repo as 2.31.2. > > Robbie > >
Re: [DISCUSS] moving the artemis examples to their own git repository
+1 We'll need to think about how we want to communicate the compatibility of each example since new examples may be added corresponding to new features in the broker. Justin On Thu, Oct 26, 2023 at 5:21 AM Robbie Gemmell wrote: > I'd like to move the artemis examples out of the main build+repo and > into a specific repo of their own. > > There are a significant number of them, most of which rarely change, > and I think it would be nicer to have them sitting standalone. Having > them in-build somewhat complicates things as they are, and also quite > significantly slows down the release process currently. The repo/build > also tends to be marked for security issues that are only related to > the examples components (obviously we'd still want to update things in > the separate repo, but theyd at least be separate). The nightly > snapshot deploy job takes an age, mostly due to the examples. There is > really no reason we should be deploying them, so I'd also stop doing > that in a shift; I wouldnt actually envisage us releasing the examples > at all. We would set up the CI to continue building them similarly to > as we do now, theyd just sit separately. > > Several other projects also use separate repos for their examples, > especially those with many of them. Specific cases I can think of > coming across most regularly are probably the multiple variants of > Camel, and Quarkus. On searching here at the ASF there do appear to be > various other projects that do this too: > > https://github.com/orgs/apache/repositories?language==examples==all > > Thoughts? > > Robbie > >
Re: [VOTE] Apache ActiveMQ 5.16.7 release
+1 Justin On Wed, Oct 25, 2023 at 9:43 AM Jean-Baptiste Onofré wrote: > Hi guys, > > I submit Apache ActiveMQ 5.16.7 release to your vote. > We did a single improvement in this release: > - improvement on OpenWire marshaller on Throwable class type > > Here's the Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12353758 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapacheactivemq-1375/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.7/ > > Git tag: activemq-5.16.7 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours or as soon as we will > have 3 binding votes. > > Thanks ! > Regards > JB > >
Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0
> Correct, it's two "isolated" Jira spaces. We have four distinct Jira projects: - https://issues.apache.org/jira/projects/AMQ - https://issues.apache.org/jira/projects/ARTEMIS - https://issues.apache.org/jira/projects/AMQNET - https://issues.apache.org/jira/projects/AMQCPP We also have 21 Git repos [1] with mirrors on GitHub: - activemq - activemq-activeio - activemq-apollo (archived) - activemq-artemis - activemq-artemis-native - activemq-cli-tools - activemq-cpp - activemq-nms-amqp - activemq-nms-api - activemq-nms-ems - activemq-nms-msmq - activemq-nms-openwire - activemq-nms-openwire-generator - activemq-nms-stomp - activemq-nms-xms - activemq-nms-zmq - activemq-openwire - activemq-protobuf - activemq-stomp - activemq-web - activemq-website As noted previously, those 4 Jira projects would be set to read-only and any open/unresolved issues would be migrated to GitHub Issues. Aside from activemq-apollo (which is archived), would each of these repos have their own GitHub Issues integration? > If you think it would make more sense to start a discussion about having Artemis as TLP... I don't think it would make more sense at this point. > I strongly believe that we could increase our contributors (especially newcomers) thanks to GH as people are familiar with it. Did the other projects which migrated to GitHub Issues do so to increase their contributions? If so, was it effective? If we had *no* presence on GitHub I would 100% agree that putting our repos there would increase contributions due to widespread familiarity with the Git integration it offers. It's just not clear to me that GitHub *Issues* itself would provide the same kind of benefit. It's worth noting that currently there's nothing stopping anybody from sending a PR to any of our repos on GitHub. Is there something specific about adopting GitHub Issues in particular (i.e. not GitHub in general) that you think will increase contributions? > In the past, we moved from CVS to SVN and from SVN to Git, for the exact same reason: features and "modern" approach. We're talking about issue management and not source control, though, right? Has ActiveMQ ever changed issue management? In my opinion, Git is a *huge* upgrade over SVN. Migrating from Jira to GitHub Issues seems more like a lateral move than an upgrade at this point. I asked previously if there were additional features in GitHub Issues that will enable new opportunities that don't currently exist in Jira, but I've not seen an explanation of any such features. > Non developers can create a GH account anyway, I don't see the issue here. This isn't an issue, per se. However, if the argument is that having to create a Jira account is bad then how is having to create a GitHub account any better? And folks will still have to subscribe to the users mailing list to ask questions or get help with diagnosing an issue unless we also start using GitHub Discussions. > Yes, all will be migrated: issues, releases, comments. For issues which were open/unresolved before the migration will there be clear links on the old Jira to the new GitHub Issue? Are you working with anybody specific from Apache infra? Perhaps they could hop on this thread and provide an overview of the process. Or is there documentation on the process you've been referencing? For what it's worth, asf.yml [2] supports "autolink_jira" which makes any Jira ID in commit messages, etc. on GitHub into a link to the actual Jira. Along with the other "jira_options" (e.g. "link") there can be pretty tight integration between Jira and GitHub. This has been very helpful in ActiveMQ Artemis to reduce the effort of switching between GitHub and Jira (something a few folks have mentioned in this thread), but it doesn't appear that this is being used in any other ActiveMQ repo. Again, I'm not saying we shouldn't move. It's just not clear to me yet why we should. Justin [1] https://gitbox.apache.org/repos/asf#activemq [2] https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features On Tue, Oct 17, 2023 at 1:13 AM Jean-Baptiste Onofré wrote: > Hi Justin > > On Mon, Oct 16, 2023 at 10:48 PM Justin Bertram > wrote: > > > > > As we have two components on Jira (one for ActiveMQ, one for > Artemis)... > > > > We have 2 brokers and 2 clients under the ActiveMQ umbrella each of which > > have their own Jira project [1]. > > Correct, it's two "isolated" Jira spaces. > Some projects have components for subprojects (Karaf for instance, > partly Camel), some projects have GitHub issues (camel-quarkus, > iceberg), some projects moved from Jira to GH Issues (Shiro). > IMHO, having https://github.com/apache/activemq and > https://github.com/apache/artemis would be clearer for the community, > each with GH issues. It's
Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0
> As we have two components on Jira (one for ActiveMQ, one for Artemis)... We have 2 brokers and 2 clients under the ActiveMQ umbrella each of which have their own Jira project [1]. > ...I proposed "only" for ActiveMQ. I realize you're only proposing this for ActiveMQ "Classic" 6.0 and beyond. My point, at least in part, is that I think we should consider this across the entire project rather than just for ActiveMQ "Classic" because a lack of consistency will be detrimental for users. Also, if the reasons for migrating are compelling for ActiveMQ "Classic" then I expect they would also be compelling for the rest of the ActiveMQ components. > The general idea is to use a more modern approach... Can you elaborate on "more modern"? This seems a bit subjective to me. > not need to request a specific Jira account, just use github I'm in favor of reducing "barriers to entry" which I believe is your goal here. Is this the main problem with Jira at the moment? At the moment users must request a Jira account as a way to mitigate spam. However, folks can also report issues via the mailing list or Slack and someone (e.g. a committer) can create a Jira on their behalf as part of fixing the issue. I've done this a number of times. Of course, even in this case users have to join the mailing list and potentially Slack which are still barriers to entry. However, having a GitHub account is also a barrier to entry and non-developer users (e.g. admins) likely won't have one. Therefore, by migrating to GitHub Issues we would be removing a barrier only for those users who already have a GitHub account. Without clear data we don't know what kind of real impact that will have. Out of the all the barriers to entry I think joining the mailing list is actually the lowest since all it requires is an email address (i.e. no "account"). Of course, we will have to deal with spam either way. > increase our contributors as the "new" comers are more familiar with GH ecosystem (outside of Apache) Jira is a widely deployed and well-known issue management platform so I think it's hard to say conclusively that it is less familiar than GitHub Issues. Is there data to suggest that moving to GitHub issues would increase contributions? I looked around a bit and the only related data I could find was the 2023 Stack Overflow Developer Survey [2] which rates Jira adoption/use pretty high. For what it's worth, there are big, popular projects at Apache which continue to use Jira. > the risk of migrating is more to lose some metadata Losing metadata is not necessarily trivial so it's worth clarifying what metadata is at risk of being lost. I'm not terribly familiar with GitHub Issues. I've reporting issues using it, but I haven't managed a project that used it. Are there features that Jira has and GitHub Issues doesn't? For example, can you perform bulk edits in GitHub Issues? Can you vote on issues? Is there an API to access issue data? If later we wanted to migrate from GitHub Issues to another platform would we be able to access all our data? All these questions may have been answered during migrations for other projects. Do we have a list of which projects have migrated? If so, I will comb through their mailing lists and educate myself. For what it's worth, the discussion on the Shiro dev list was pretty short. > the migration plan is pretty simple, we already have the tooling almost there with INFRA The plan may be simple, but it's still not clear what the plan actually is. If the tooling is "almost there" then what's there an what isn't? Would the plan be to make all the Jira projects read-only and migrate open issues? If so, do all the existing comments on the open issues get migrated? To be clear, I'm not saying we *shouldn't* migrate. It's just that the details aren't clear so I can't make an informed decision yet. Justin [1] https://activemq.apache.org/issues [2] https://survey.stackoverflow.co/2023/#most-popular-technologies-office-stack-async On Mon, Oct 16, 2023 at 12:26 PM Jean-Baptiste Onofré wrote: > Hi Justin, > > As we have two components on Jira (one for ActiveMQ, one for Artemis), > I proposed "only" for ActiveMQ. > > The general idea is to use a more modern approach for ActiveMQ: > - not need to request a specific Jira account, just use github > - increase our contributors as the "new" comers are more familiar with > GH ecosystem (outside of Apache) > - the risk of migrating is more to lose some metadata (even if it > didn't happen when migrating shiro or ops4j) > - the migration plan is pretty simple, we already have the tooling > almost there with INFRA > > Regards > JB > > On Mon, Oct 16, 2023 at 6:28 PM Justin Bertram > wrote: > > > > It may be better to break this up into separate [DISCUSS] threads -
Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0
It may be better to break this up into separate [DISCUSS] threads - one for Apache Jenkins and GitHub Actions and one for Apache Jira and GitHub Issues. In any event, it would be good to get clear details on a few different points: - What specifically are the problems with the existing solution? - How are those problems addressed by the proposed solution? Are there additional features in the proposed solution that will enable new opportunities that don't currently exist? - What are the risks of migrating? - What is the migration plan? Once these details are clear we will be able to make an informed decision about what action we should take. Lastly, I think these issues should be considered across ActiveMQ as a whole and not just for any individual component. I believe that having different ways of doing the same thing for different components on the same project is going to be confusing and frustrating for users and developers alike. Justin On Fri, Oct 13, 2023 at 11:13 AM Jean-Baptiste Onofré wrote: > Hi guys, > > Even if we are pretty busy and focused on ActiveMQ 6.0.0 release > preparation (as said in another email, I should be able to submit the > release to vote next week), I think we can anticipate a little the > future of ActiveMQ. > ActiveMQ 6.0.0 is a major milestone for the project, heading to a more > modern approach (I started a PoC to remove Spring dep and using SPI > like approach at broker side, I will keep you posted about that) for > the codebase, website, and our developer experience. > > I would like to discuss: > 1. Moving from Apache Jenkins to GitHub Actions, using multiple > workflows, more decoupled, with potentially more "executors" to build > and leveraging GitHub Actions "modules". > 2. Moving from Apache Jira to GitHub Issues. Several Apache projects > already use GitHub Issues. At OPS4J we also migrated from Jira to GH > Issues. We were able to import everything from Jira without losing > data. I think it would also be a good opportunity to do some cleanup, > maybe starting with only tickets for 6.x. > > Thoughts ? > > Regards > JB > >
Re: [VOTE] Apache ActiveMQ Artemis 2.31.0 (RC2)
+1 Very nice release! Justin On Fri, Sep 15, 2023 at 2:50 PM Clebert Suconic wrote: > I would like to propose an Apache ActiveMQ Artemis 2.31.0 release. > This is the 2nd Respin of the release (RC2) > > This was a large release overall with many improvements, and I'm proud > of what we accomplished on this release. Thanks for all who > contributed to this release by both raising JIRAs or contributing > changes: > > * Improvements on the Artemis CLI: > > * Introduced a new feature, Artemis shell, as part of 2.31.0. When > you run ./artemis shell, a new terminal screen will help you navigate > through the CLI commands. > * The shell terminal will also be presented when you run ./artemis. > * You can use bash auto-complete. Run ./artemis auto-complete to > generate a bash script that provides auto-complete information for > your bash shell. > * Added a CLI cluster verification tool to help you monitor your > broker topologies. Type ./artemis check cluster to access this > functionality. > * You can now use ./artemis queue stat to verify the message counts > on the entire cluster topology when clustering is in use. > > AMQP Federation: > * Added AMQP Federation support to broker connections. > > * MQTT Session State Persistence: > > * Paging JDBC Persistence performance was improved significantly > > * The documentation was converted to Ascii Doc. > > * Many other bug fixes and improvements, as usual. > > > The full JIRA release notes can be found here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353446 > > Ths git commit report is here: > > https://activemq.apache.org/components/artemis/download/commit-report-2.31.0 > > Source and binary distributions can be found here: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.0/ > > The Maven repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1370 > > In case you want to give it a try with the maven repo on examples: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html > > The release was tagged as 2.31.0 on git > > I will update the website after the vote has passed. > > > [ ] +1 approve this release > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here's my +1 Binding vote > >
Re: [DISCUSS] ActiveMQ 6.0.0 revisited
I don't have a deep familiarity with the internals here so some of the fundamentals behind the changes aren't clear to me. Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How tightly is "Classic" coupled with Spring? Is the coupling with Spring also why the code-base is being moved whole-sale to Jakarta? It's been a little while now, but when Artemis implemented Jakarta support back in early 2021 I don't recall any disruption for current users and no major version change was needed. Both Java EE and Jakarta EE implementations are based on the same code-base. Is something like that not possible here? It would simplify maintenance a lot since fixes/features wouldn't have to be back-ported. Justin On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > First, I realize that this thread is likely to cause a fight based on past > history and probably not go anywhere, but with the work being done > with Jakarta for AMQ 5.x I think it's time to at least bring up the > ActiveMQ 6.0 discussion. > > With all the breaking changes currently targeted for version 5.19.x, such > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty > upgrades and now potentially major OSGi changes, it makes zero sense to me > to have this next AMQ version as version 5.19.0 as it's completely > incompatible with the previous version 5.18.x. Users are likely going to be > in for a rude awakening when trying to upgrade and will be quite confused > as to why so much is different. > > The Jakarta changes should really be a major version upgrade so that it's > much more clear to users that it's very different from the previous > version. Another major benefit of going with version 6.0 is that it frees > up the previous javax releases to continue on with 5.19 or 5.20 because we > will likely need to support the older javax releases for quite a while. > > Also, from my point of view it seems pretty clear that the original goal > for Artemis to become AMQ 6.0.0 is never going to happen. Artemis has had > its own branding and versioning for several years now and will likely > continue that way and not change so I don't really see that as a reason to > not bump AMQ 5.x to 6.x with all the major breaking changes. > > Anyways, I figure there won't be much agreement here but thought I should > at least throw it out there before we go and release 5.19.x with such major > breaking changes. >
Re: [DISCUSS] ActiveMQ 6.0.0 revisited
I still think it's important to have some kind of specific name or tag (e.g. "Classic") to differentiate the two brokers, especially on the website where the two are "next to" each other. Using a version number just doesn't cut it in my opinion. For example, what happens when Artemis' version number catches up to 6.x, etc.? You won't be able to use the version number anymore to differentiate the two. Clarity is really important for everyone in the community - especially in support scenarios. I work a lot on Stack Overflow with folks using both brokers and having a verbal umbrella for each is extremely helpful. Justin On Tue, Sep 12, 2023 at 8:35 AM Jean-Baptiste Onofré wrote: > That makes lot of sense to me ! We will have: > > - ActiveMQ 5.18.x > - ActiveMQ 6.x.x > - ActiveMQ 7.x.x > - ActiveMQ Artemis 2.x > - ActiveMQ Artemis 3.x > > So, I propose to have two "spaces" on website: > http://activemq.apache.org/activemq > http://activemq.apache.org/artemis > > The index.html will list the two spaces and users will go to one or > another. > > Thoughts ? > > Regards > JB > > On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell > wrote: > > > > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change. > > > > On Tue, 12 Sept 2023 at 13:34, Francois Papon > > wrote: > > > > > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis? > > > > > > On 12/09/2023 14:14, Robbie Gemmell wrote: > > > > That is how I refer to them, or more fully as ActiveMQ 5.x like > below, > > > > and ActiveMQ Artemis. > > > > > > > > Same as last time this was discussed, I dont consider "Classic" part > > > > of the actual name, just a reflective description label, quoted for a > > > > reason. > > > > > > > > On Tue, 12 Sept 2023 at 12:48, fpapon wrote: > > > >> Why not simply ActiveMQ and Artemis? > > > >> > > > >> This is how people used to name the 2 projects, I never eared > someone > > > >> say "ActiveMQ Classic". > > > >> > > > >> regards, > > > >> > > > >> François > > > >> > > > >> On 12/09/2023 13:07, Robbie Gemmell wrote: > > > >>> Same thoughts as last time you proposed it really. Adding Leto > would > > > >>> not be an improvement for me, more actually the reverse. I think > it's > > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more > > > >>> confusing. Describing something as 'classic' is a pretty normal / > > > >>> well-known thing, I think a user even noted that on the original > > > >>> thread. > > > >>> > > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > > > Is it a good time to talk about ActiveMQ "Something" instead of > > > "Classic" ? (I hate this "classic" naming (it sounds weird to me) > and > > > most of people uses simply Artemis and ActiveMQ as name) > > > > > > I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother > of > > > Artemis in Greek mythology) to have a clear distinction between > the > > > two subprojects. Thoughts ? :) > > > > > > If it's too "sensible", please ignore :) > > > > > > Regards > > > JB > > > > > > On Tue, Sep 12, 2023 at 11:11 AM Gary Tully > wrote: > > > > makes sense, but please keep a clear distinction - activemq > classic 6.0.0 > > > > activemq X may still evolve to combine the best of both. > > > > > > > > On Mon, 11 Sept 2023 at 22:15, Christopher Shannon < > > > > christopher.l.shan...@gmail.com> wrote: > > > > > > > >> First, I realize that this thread is likely to cause a fight > based on past > > > >> history and probably not go anywhere, but with the work being > done > > > >> with Jakarta for AMQ 5.x I think it's time to at least bring up > the > > > >> ActiveMQ 6.0 discussion. > > > >> > > > >> With all the breaking changes currently targeted for version > 5.19.x, such > > > >> as the Jakarta switch from javax, requiring JDK 17, major > Spring and Jetty > > > >> upgrades and now potentially major OSGi changes, it makes zero > sense to me > > > >> to have this next AMQ version as version 5.19.0 as it's > completely > > > >> incompatible with the previous version 5.18.x. Users are likely > going to be > > > >> in for a rude awakening when trying to upgrade and will be > quite confused > > > >> as to why so much is different. > > > >> > > > >> The Jakarta changes should really be a major version upgrade so > that it's > > > >> much more clear to users that it's very different from the > previous > > > >> version. Another major benefit of going with version 6.0 is > that it frees > > > >> up the previous javax releases to continue on with 5.19 or 5.20 > because we > > > >> will likely need to support the older javax releases for quite > a while. > > > >> > > > >> Also, from my point of view it seems pretty clear that the > original goal > > > >> for Artemis to become AMQ 6.0.0 is never going to happen. > Artemis has had >
Re: snapshots repo cleanup
I have no objections, but I do have a question. What is pushing those snapshots? Justin On Mon, Jul 31, 2023 at 12:02 PM Robbie Gemmell wrote: > Infra have said they would be happier with PMC consensus first for a > bulk clear (which I suggested as picking out individual stuff to clear > or keep would be a nightmare), so lets go with a lazy consensus poll: > > Does anyone object to bulk-clearing of the stale contents of the > snapshot repo, and having the CI jobs repopulating only fresh stuff? > > Lets say lazy consensus will be assumed on Friday failing discussion > otherwise. > > Robbie > > On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell > wrote: > > > > Hi folks, just a note that I have raised a JIRA to ask Infra to clear > > out the snapshots repo, as I came to realise it is full of a > > considerable amount of stale junk, including things that either add > > clutter or just actively mislead people. Once cleared the nightly jobs > > can then deploy just the stuff currently being worked on. > > > > https://issues.apache.org/jira/browse/INFRA-24848 > >
Re: EnterpriseDB support
Which version of ActiveMQ are you needing to support EDB? Justin On Mon, Jul 31, 2023 at 5:43 AM ISTVAN, ROBERT wrote: > Dear Team, > I'd like to ask you to add support to EnterpriseDB, Postgresql dialect > should be extended with 'edb'. > > Thank you in advance, > Robert > >
[ANNOUNCE] ActiveMQ Artemis 2.30.0 Released
I'm pleased to announce the release of ActiveMQ Artemis 2.30.0. Downloads are now available at: https://activemq.apache.org/components/artemis/download/ For a complete list of updates: https://activemq.apache.org/components/artemis/download/release-notes-2.30.0 This is mainly a bug-fix release with a few small improvements and a handful of dependency upgrades. Many thanks for all the contributors to this release. Justin
[RESULT] [VOTE] Apache ActiveMQ Artemis 2.30.0
The vote passes with 7 binding votes. The following votes were received: +1 (binding): Justin Bertram, Tim Bish, Clebert Suconic, JB Onoforé, Domenico Bruscino, Gary Tully, Robbie Gemmell Thank you to everyone who contributed and took the time to review the release candidate and vote. I'm promoting the artifacts on Maven Central and dist.apache.org. I will update the website and send the announcement. Justin
[VOTE] Apache ActiveMQ Artemis 2.30.0
I would like to propose an Apache ActiveMQ Artemis 2.30.0 release. This is mainly a bug-fix release with a few small improvements and a handful of dependency upgrades. The release notes can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353357 Ths git commit report is here: https://activemq.apache.org/components/artemis/download/commit-report-2.30.0.html Source and binary distributions can be found here: https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.30.0/ The Maven repository is here: https://repository.apache.org/content/repositories/orgapacheactivemq-1367 In case you want to give it a try with the maven repo on examples: https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html The source tag: https://github.com/apache/activemq-artemis/tree/2.30.0 I will update the website after the vote has passed. [ ] +1 approve this release [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here's my +1 Justin
[HEADS-UP] Artemis 2.30.0
I plan on cutting 2.30.0 tomorrow and hopefully kicking off a vote as well. Justin
Re: Jakarta Messaging TCK setup
Would the contents of that repository (assuming a TCK is set up there) not be out of date at this point? It seems like we could just grab the relevant TCK [1] from Eclipse and create a new repo with it. What's the benefit of inspecting or using the old repo? Justin [1] https://download.eclipse.org/ee4j/jakartaee-tck/ On Wed, Jul 12, 2023 at 8:47 AM David Blevins wrote: > Hey All, > > Matt and I were talking on the Jakarta lists about getting the Jakarta > Messaging TCK setup for ActiveMQ Classic. > > I know there was a TCK setup at some point as I’ve sat next to Hiram while > he ran it way back in the day. I don’t recall if he was running the > Geronimo TCK setup, however, or if he had managed to get a setup with just > plain ActiveMQ. > > If there was a TCK setup, it would probably be here: > > - svn list https://svn.apache.org/repos/tck/activemq-tck > > Even if you are a committer, you would not have access unless you were > around in the 2004-2010 timeframe and agreed to be confidential with the > TCK materials and results. > > If there are any folks around from back then, can you quickly check to see > if something is there? > > If so, we will now be able to safely make that repo public and convert it > to git. > > > -David > >
Re: [DISCUSS] Naming convention for official Docker images
I'm fine with using: - apache/activemq-classic - apache/activemq-artemis Justin On Mon, Jul 10, 2023 at 9:55 AM Jean-Baptiste Onofré wrote: > Hi Justin, > > It has been discussed but not the name specifically. > > As we use apache/activemq-artemis, I thought "logical" to use > apache/activemq (but maybe activemq-classic makes more sense). > > I'm not sure we will be able to use apache/activemq/classic and > apache/activemq/artemis, but we can definitely use > apache/activemq-classic as apache/activemq-artemis. > > I can rename right now. > > Thoughts ? > > Regards > JB > > > On Mon, Jul 10, 2023 at 3:57 PM Justin Bertram > wrote: > > > > This weekend JB announced [1] the availability of official Docker images > > for ActiveMQ "Classic" in the "apache/activemq" namespace [2]. > > > > Perhaps I missed it, but I don't recall (and can't find) any discussion > of > > or notification about this. Users will certainly expect images for both > > "Classic" and Artemis so my concern is regarding the namespace. If both > > "Classic" and Artemis share the apache/activemq namespace directly then > > there may eventually be version number conflicts and there certainly will > > be confusion about which version is which. > > > > Before these images are widely adopted I think the namespace should be > > clarified just as it is on the website so that ActiveMQ "Classic" uses > > "apache/activemq/classic" and ActiveMQ Artemis uses > > "apache/activemq/artemis". > > > > Thoughts? > > > > > > Justin > > > > [1] https://lists.apache.org/thread/4cqbm0gsbj184vrp13yorcd2rrbdcsmx > > [2] https://hub.docker.com/r/apache/activemq/tags > >
[DISCUSS] Naming convention for official Docker images
This weekend JB announced [1] the availability of official Docker images for ActiveMQ "Classic" in the "apache/activemq" namespace [2]. Perhaps I missed it, but I don't recall (and can't find) any discussion of or notification about this. Users will certainly expect images for both "Classic" and Artemis so my concern is regarding the namespace. If both "Classic" and Artemis share the apache/activemq namespace directly then there may eventually be version number conflicts and there certainly will be confusion about which version is which. Before these images are widely adopted I think the namespace should be clarified just as it is on the website so that ActiveMQ "Classic" uses "apache/activemq/classic" and ActiveMQ Artemis uses "apache/activemq/artemis". Thoughts? Justin [1] https://lists.apache.org/thread/4cqbm0gsbj184vrp13yorcd2rrbdcsmx [2] https://hub.docker.com/r/apache/activemq/tags
Re: [HEADS-UP] ActiveMQ Artemis release
Both of those PRs have conflicts now. Resolve and rebase and I'll look to merge them. Thanks! Justin On Wed, Jun 14, 2023 at 2:45 PM Roskvist Anton wrote: > Looking forward to a new release, though if the following PRs are looking > good I would really appreciate if they could be considered for the 2.29.0 > release as well. > https://github.com/apache/activemq-artemis/pull/4383 > https://github.com/apache/activemq-artemis/pull/4382 > > Nothing major but would solve a couple of small annoyances for one of my > use cases. Thanks! > > This email message (including its attachments) is confidential and may > contain privileged information and is intended solely for the use of the > individual and/or entity to whom it is addressed. If you are not the > intended recipient of this e-mail you may not disseminate, distribute or > copy this e-mail (including its attachments), or any part thereof. If this > e-mail is received in error, please notify the sender immediately by return > e-mail and make sure that this e-mail (including its attachments), and all > copies thereof, are immediately deleted from your system. Please further > note that when you communicate with us via email or visit our website we > process your personal data. See our privacy policy for more information > about how we process it: https://www.volvogroup.com/en-en/privacy.html >
Re: Remove Jackson from ActiveMQ classic
For what it's worth, Artemis uses JSON-P [1] since it's a standard, simple API. We use Apache Johnzon for the implementation. It does everything we need given our relatively basic use-cases. Additionally, we wrap the API so that all the broker code can use the wrapper and the wrapper can be modified to work in Java EE or Jakarta EE environments. Justin [1] https://javaee.github.io/javaee-spec/javadocs/javax/json/package-summary.html On Tue, May 16, 2023 at 6:02 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Yes, this keeps coming up and as JB said I don't see a problem with > Jackson, it can be updated for CVEs and works very well and is quite > feature rich in case we need it. > > If we are going to do any JSON serialization I don't want to re-invent the > wheel and create our own serializer, so we should at least use an existing > library, even if we make it pluggable like JSON-B. > > There's alternatives too like Gson if we wanted something > smaller/lightweight. > > On Tue, May 16, 2023 at 3:11 PM Jean-Baptiste Onofré > wrote: > > > Hi, > > > > We discussed this already in the past. IMHO, we can replace jackson by > > just sax (no need to use JSON-B regarding our usage). > > > > That sasid, I don't see any huge issue with Jackson: it works fine and > > we keep the versions up to date to fix CVE. > > > > The only interesting move would be to use SAX parsing directly instead > > of a mapper. > > > > Regards > > JB > > > > On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro > > wrote: > > > > > > Hi all, > > > > > > Jackson seems to be frequently affected by CVEs and it's really a pain > > for > > > users. > > > > > > Looks like Jackson is only used in the WebConsole to read/write a few > > > attributes. I'm sure we can get rid of it and either use a standard API > > so > > > one can plugin any implementation, or just write down a utility class > to > > > parse the small attribute we have to. > > > > > > thoughts? > > > > > > I'm happy to do a PR to remove it if that's the consensus. > > > > > > -- > > > Jean-Louis Monteiro > > > http://twitter.com/jlouismonteiro > > > http://www.tomitribe.com > > >
Re: server not starting on port 61616 for some reason.
The "dev" list is for folks working directly on one of the ActiveMQ code-bases (as noted on the website [1]). For questions like yours involving the *use* of the broker you should use the "users" list. Please send this question to the users list and include details like which broker you're using, which version, and what your configuration is. Thanks! Justin [1] https://activemq.apache.org/contact On Thu, Apr 13, 2023 at 11:11 AM Wendell Hatcher < wendellhatcher1...@gmail.com> wrote: > Hello, I have an issue where one server good starts on 61616 and the other > both have the same configuration doesnt. I confirmed that both have the > same configs. > > [12:02 PM] Hatcher, Wendell > > r ~]# netstat -na | grep 616 | grep -v localhost | grep LISTEN > tcp0 0 :::61616:::* > LISTEN > ~]# netstat -na | grep -v localhost | grep LISTEN > tcp0 0 0.0.0.0:47500.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:34766 0.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:111 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:9010 0.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:15560.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:21460 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:1557 0.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:13782 0.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:22 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:631 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:250.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:6010 0.0.0.0:* > LISTEN > tcp0 0 0.0.0.0:13724 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:14719 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:13089 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:10946 0.0.0.0:* > LISTEN > tcp0 0 127.0.0.1:57986 0.0.0.0:* > LISTEN > tcp0 0 :::20712:::* > LISTEN > tcp0 0 :::111 :::* > LISTEN > tcp0 0 :::61616:::* > LISTEN > tcp0 0 :::1556 :::* > LISTEN > tcp0 0 :::22 :::* > LISTEN > tcp0 0 ::1:631 :::* > LISTEN > tcp0 0 ::1:6010:::* > LISTEN > tcp0 0 :::11099:::* > LISTEN > tcp0 0 :::43164:::* > LISTEN > tcp0 0 :::8161 :::* > LISTEN > tcp0 0 :::10338:::* > LISTEN > tcp0 0 :::5666 :::* > LISTEN > unix 2 [ ACC ] STREAM LISTENING 15350 > /var/lib/fireeye/xagtshare/__7dea7cf6_@.sock > unix 2 [ ACC ] STREAM LISTENING 13224 > /usr/openv/var/vnetd/terminate_vnetd.uds > unix 2 [ ACC ] STREAM LISTENING 13311 > /usr/openv/var/vnetd/terminate_bpcd.uds > unix 2 [ ACC ] STREAM LISTENING 72800235 > /var/lib/sss/pipes/private/sbus-dp_jewels.local.27395 > unix 2 [ ACC ] STREAM LISTENING 12387 > @/var/run/hald/dbus-CZgGxivFsR > unix 2 [ ACC ] STREAM LISTENING 7775 > @/com/ubuntu/upstart > unix 2 [ ACC ] STREAM LISTENING 13320 > /usr/openv/var/vnetd/bpcd.uds > unix 2 [ ACC ] STREAM LISTENING 12747 > /var/lib/sss/pipes/pam > unix 2 [ ACC ] STREAM LISTENING 12749 > /var/lib/sss/pipes/private/pam > unix 2 [ ACC ] STREAM LISTENING 70186625 > /var/lib/sss/pipes/nss > unix 2 [ ACC ] STREAM LISTENING 12724 > /var/lib/sss/pipes/private/sbus-monitor > unix 2 [ ACC ] STREAM LISTENING 70148250 > /var/lib/sss/pipes/private/sbus-dp_irving.zalecorp.com.22038 > unix 2 [ ACC ] STREAM LISTENING 12382 > @/var/run/hald/dbus-jmkY46savZ > unix 2 [ ACC ] STREAM LISTENING 1937169 > /usr/openv/var/proxy.d/proxy_helper-inbound_proxy-0-2299.uds > unix 2 [ ACC ] STREAM LISTENING 11236 > /var/run/vmware/guestServicePipe > unix 2 [ ACC ] STREAM LISTENING 12282 > /var/run/cups/cups.sock > unix 2 [ ACC ] STREAM LISTENING 11716 > /var/run/rpcbind.sock > unix 2 [ ACC ] STREAM LISTENING 12217 > /var/run/dbus/system_bus_socket > unix 2 [ ACC ] STREAM LISTENING 13807 > /var/run/abrt/abrt.socket > unix 2 [ ACC ] STREAM LISTENING 12349 > /var/run/acpid.socket > unix 2 [ ACC ] STREAM LISTENING 7044234 @listener-32675-0 > unix 2 [ ACC ] STREAM LISTENING 18959 > /var/lib/fireeye/xagtshare/__a5500fb_@.sock > > > [12:02 PM] Hatcher, Wendell > > t > exit > apache-activemq-5.13.1]# netstat -na | grep
Re: ASF board report due in two days!
FWIW, I contributed to it earlier today.
Justin
On Tue, Apr 11, 2023 at 2:45 PM Bruce Snyder wrote:
> So far, there have been zero contributions to the board report and it's due
> tomorrow. Please contribute to this month's board report so I can submit it
> tomorrow.
>
> Bruce
>
> On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder
> wrote:
>
> > It looks like we got notified late again regarding this month's board
> > report and it's due in two days!
> >
> > Please provide your contributions for this board report by adding them to
> > the following file already in the git repo:
> >
> >
> >
> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> >
> >
> > Bruce
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > http://bsnyder.org/
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
For what it's worth Artemis created new coordinates for the Jakarta modules and left the existing ones the same. Folks who are migrating are actually touching their applications in most (if not all) circumstances. It makes sense to require them to change the GAV. In my opinion folks who just want to upgrade their existing (i.e. javax) systems shouldn't have to change anything but the version number. Justin On Mon, Apr 3, 2023 at 6:20 AM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Matt, > > My main concern with that is with new -javax modules everyone has to change > to new GAV and then they have to change GAV again if we drop the javax. > > But this might just be the way it is and users will have to make changes to > their build that is more than just a version change. > > On Fri, Mar 31, 2023 at 2:17 PM Matt Pavlovich wrote: > > > Hi Christopher- > > > > After taking yesterday to get most of the way through the jakarta > > conversion, I think we can go without the version gap. > > > > I think option #1 gives us the best approach. After a period of time we > > can just ‘drop’ the javax modules and not have to cause users to change > > anything else back to have clean GAV coordinates. > > > > Thanks, > > Matt Pavlovich > > > > > On Mar 30, 2023, at 3:49 PM, Christopher Shannon < > > christopher.l.shan...@gmail.com> wrote: > > > > > > Thanks Matt for bringing this up. We definitely need to figure out a > path > > > forward as there is a lot of confusion about this still and users are > > > getting bit by it when trying to upgrade to Spring 6 and Spring boot 3. > > > > > > Ultimately I think we will need to support both javax and jakarta for > > quite > > > a while because while some users are going to want to use newer > > > technologies that require jakarta (like Spring 6 ) others will be happy > > to > > > stay on the old APIs for a while. So the question becomes what is the > > best > > > way to do that. I do think that some sort of repackaging is probably > the > > > way to go like we did for the client but to do it for all the relevant > > > modules and release both. We can keep 5.18.x as a long running branch > to > > > back port but it would still be nice if the latest worked for either > API > > > (ie 5.19.x). I'm thinking more about it and we can probably just do it > in > > > 5.19.x and don't need a gap version. > > > > > > I can see 3 ways to release both: > > > > > > *1) Create duplicate modules (like we did with the client for jakarta > in > > > 5.18.x). *This works but means a lot of extra modules to maintain but > is > > > probably the most flexible as you can do custom things in each module > > > easily. We could create BOM files for people to use to import the right > > > things to keep things consistent. > > > > > > > > > org.apache.activemq > > > activemq-broker-javax > > > 5.19.0 > > > > > > > > > > > > org.apache.activemq > > > activemq-broker-jakarta > > > 5.19.0 > > > > > > > > > *2) Don't add new modules, just keep the same ones but have each module > > > build 2 jars using classifiers. *We could just have each module build 2 > > > jars and repackage. My primary concern about sharing the same module > for > > > both APIs would be if the Jakarta API becomes different enough that > > > repackaging doesn't work due to changes between it and javax but we > might > > > still be able to make this work by having each classified jar only pull > > in > > > certain things. > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0 > > > javax > > > > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0 > > > jakarta > > > > > > > > > *3) Just build with a different version (this is what Guava does with > jre > > > and android). *This is probably the most annoying as you would need to > > > re-package and then I guess use a different version when building. > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0-javax > > > > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0-jakarta > > > > > > > > > > > > On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik > > wrote: > > > > > >> From a lurker position here, I just wanted to point out that Jetty is > > >> evidently making a version 12 which will support both javax. and > > jakarta. > > >> in the same server. > > >> https://www.eclipse.org/jetty/download.php > > >> > > >> Kind regards, > > >> Endre > > >> > > >> > > >> On Thu, Mar 30, 2023 at 9:54 PM Jean-Baptiste Onofré > > > >> wrote: > > >> > > >>> Hi, > > >>> > > >>> I agree with the plan but why not keep 5.19.0-SNAPSHOT on main ? > > >>> We have the activemq-5.18.x branch already that could be LTS where we > > >>> keep javax namespace. > > >>> > > >>> Regards > > >>> JB > > >>> > > >>> On Thu, Mar 30, 2023 at 7:54 PM Matt Pavlovich > > >> wrote: > > > > Hello All- > > > > I started building a jakarta-based broker for ActiveMQ 5.x and > propose
Re: wildfly 26.1.2 support
Please send your question to the ActiveMQ "users" list at us...@activemq.apache.org. This is the "dev" list and is for folks working directly on an ActiveMQ code-base as noted on the website [1]. Also, when you send your question to the ActiveMQ users list please elaborate on what you mean by serialization/deserialization in this context. Thanks! Justin [1] https://activemq.apache.org/contact On Fri, Mar 17, 2023 at 4:55 PM Walter Krix (Nokia) wrote: > Dear ActiveMQ Artemis Developers, > > > I am writing to inquire about the setup of the ActiveMQ Artemis subsystem > in Wildfly 26.1.2. Specifically, I am interested in configuring Artemis to > work without serialization/deserialization. > > > I would greatly appreciate it if you could provide me with information on > how to achieve this configuration, if it is possible at all. Any guidance, > documentation or resources you can offer to assist me in this matter would > be most helpful. > > > Thank you for your time and attention to this matter. I look forward to > hearing back from you soon. > > > Sincerely, > > Walter Krix >
Re: [Discuss] automated github messages on a separate list
Art, can you clarify the "hint, hint"? Perhaps I missed some context somewhere. The GitBox emails stopped hitting the dev list over 4 years ago now. Are you saying that you haven't looked over the dev list in 4 years? :-) Justin On Tue, Mar 7, 2023 at 11:01 AM Arthur Naseef wrote: > Just saw this from a rare look over DEV list messages (hint hint) ;-). > > So glad to see this action. Easy-to-Use is top priority, and a dev list > that requires filtering to use - why? Just why? > > Art > > > On Thu, Mar 14, 2019 at 11:40 AM jgenender wrote: > > > +1 to github notifications on another list. It does indeed drown out the > > communication here and not everyone can use a filter. I use Nabble, so > its > > not as easy. > > > > Jeff > > > > > > > > -- > > Sent from: > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html > > >
Re: Artemis Router Architecture
Can you elaborate on your use-case at all? The main class responsible for routing is org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl. Justin On Wed, Mar 1, 2023 at 4:55 PM Brian Ramprasad wrote: > Hi Clebert, > > Thanks for your reply. > > Yes, I would still like to learn how the routing works. I am PhD student > and my work involves using Artemis in a way that is likely very atypical as > compared to the common use cases. > > Do you know if there is any documentation or can you provide the names of > a few Java classes that are central to the router? > > > > > > > > On Mar 1, 2023, at 5:16 PM, Clebert Suconic > wrote: > > > > Are you sure you need to do that? > > > > routing is so optimized right now... if you don't use transactions, a > > single consumer, all that's happening is just sending straight to a > > consumer. > > > > > > If you start adding multiple consumers, than routing will probably > > need some extra work to do, but other than that is pretty optimized > > right now. > > > > On Wed, Mar 1, 2023 at 4:56 PM Brian Ramprasad > wrote: > >> > >> Hi, > >> > >> I am looking for information about how the routing function works in > Artemis. Specifically, I am trying to understand what internal service > inside the broker is invoked once a msg has been read off the network in > order to determine where to forward the message. Additionally, I am trying > to understand the service that is then responsible for moving that message > to an outbound queue where a consumer is waiting to receive that message. > >> > >> I am trying to determine if I can optimize the routing mechanism by > removing any unneeded functionality to reduce overhead to support a > specific consumer use case that I have. > >> > >> Any information is appreciated! > >> > >> Thanks > >> Brian R > > > > > > > > -- > > Clebert Suconic > >
Re: xbean link
Thanks for the notification! I've fixed that page and all the other pages referring to the defunct XBean domain. Justin On Wed, Mar 1, 2023 at 4:45 AM Jess Bring-Larsen wrote: > Hi group, > > At the top of the documentarion page: > https://activemq.apache.org/xml-configuration > there is a "XBean" link pointing to a site I suspect was not the intention. > > Best regards, Jess >
Re: ASF Board Report
I added a few Artemis-related details. Justin On Mon, Feb 6, 2023 at 2:46 PM Bruce Snyder wrote: > I need your help -- this month's board report must be submitted tomorrow > and there have been zero contributions. I need some folks to input to form > this report in the next 24 hours by adding your contributions the following > file in git: > > > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt > > We already missed last month's report submission due to a late sending of > the notice email. Please don't make us wait another month. > > Bruce > > On Wed, Feb 1, 2023 at 10:10 AM Bruce Snyder > wrote: > > > REMINDER: We now have 7 days to submit the ASF Board Report. > > > > Please provide your contributions for this report via the following file > > in the git repo: > > > > > > > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt > > > > > > Bruce > > > > On Wed, Jan 25, 2023 at 5:30 PM Bruce Snyder > > wrote: > > > >> And today the notification for the February board report just came out. > I > >> will submit the report by Feb 7. > >> > >> Please provide your contributions for the board report by adding them to > >> the following file using git: > >> > >> > >> > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt > >> > >> > >> Bruce > >> > >> On Wed, Jan 25, 2023 at 11:02 AM Bruce Snyder > >> wrote: > >> > >>> Ok, then let's use this file to gather contributions for next month's > >>> ActiveMQ board report. > >>> > >>> Bruce > >>> > >>> On Wed, Jan 25, 2023 at 2:13 AM Robbie Gemmell < > robbie.gemm...@gmail.com> > >>> wrote: > >>> > >>>> Yep, that is exactly what the file was added for and used to prepare > >>>> the previous board report draft, following previous discussions about > >>>> doing so. Its the one I was enquiring whether to delete or not earlier > >>>> in the thread. > >>>> > >>>> On Tue, 24 Jan 2023 at 18:26, Bruce Snyder > >>>> wrote: > >>>> > > >>>> > There is a file at the following URL named > >>>> DRAFT-ActiveMQ-board-report.txt, > >>>> > can we use this for gathering contributions to the board report? > >>>> > > >>>> > > https://github.com/apache/activemq-website/tree/main/src/team/reports > >>>> > > >>>> > If not this file, please provide a suggestion. > >>>> > > >>>> > Bruce > >>>> > > >>>> > On Wed, Jan 18, 2023 at 12:57 PM Justin Bertram < > jbert...@apache.org> > >>>> wrote: > >>>> > > >>>> > > There's an ASF tool where you can add the release information [1] > >>>> and that > >>>> > > information is then available to Bruce and he just copies and > >>>> pastes it > >>>> > > into the report before he submits it. So the release process > should > >>>> include > >>>> > > using this tool. > >>>> > > > >>>> > > > >>>> > > Justin > >>>> > > > >>>> > > [1] https://reporter.apache.org/addrelease.html?activemq > >>>> > > > >>>> > > On Wed, Jan 18, 2023 at 11:15 AM Clebert Suconic < > >>>> > > clebert.suco...@gmail.com> > >>>> > > wrote: > >>>> > > > >>>> > > > fine... we could start filling the draft as releases are done, > as > >>>> part > >>>> > > > of the release procedure? > >>>> > > > > >>>> > > > On Wed, Jan 18, 2023 at 10:39 AM Bruce Snyder < > >>>> bruce.sny...@gmail.com> > >>>> > > > wrote: > >>>> > > > > > >>>> > > > > I would rather employ the prepare-draft-in-site-git-repo > >>>> approach > >>>> > > because > >>>> > > > > it will result in a report format already prepared that can be > >>>> > > > copy/pasted > >>>> > > > > direct
Re: [DISCUSS] discontinue PDF, EPUB, & MOBI docs for Artemis
Consider this thread closed. Justin On Mon, Feb 6, 2023 at 11:55 AM Justin Bertram wrote: > Fair enough. I'll resend to the users list. > > > Justin > > On Mon, Feb 6, 2023 at 11:41 AM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > >> This seems like a question much better suited for the user mailing list to >> see if any users actually use those formats. >> >> On Mon, Feb 6, 2023 at 12:26 PM Clebert Suconic < >> clebert.suco...@gmail.com> >> wrote: >> >> > I wonder if anyone ever uses them? >> > >> > We used to make them because it was cool to do it years ago... now it >> > feels like an useless step. >> > >> > Does anyone actually see value on them? >> > >> > On Mon, Feb 6, 2023 at 11:34 AM Justin Bertram >> > wrote: >> > > >> > > Currently as part of the release process for Artemis we build docs in >> > these >> > > formats: >> > > - HTML >> > > - PDF >> > > - EPUB >> > > - MOBI >> > > >> > > I think we should only build docs in HTML and stop building them in >> PDF, >> > > EPUB, & MOBI. Building the extra formats adds a surprising overhead to >> > the >> > > release process, and I don't think they are useful enough to warrant >> the >> > > effort. >> > > >> > > Thoughts? >> > > >> > > >> > > Justin >> > >> > >> > >> > -- >> > Clebert Suconic >> > >> >
Re: [DISCUSS] discontinue PDF, EPUB, & MOBI docs for Artemis
Fair enough. I'll resend to the users list. Justin On Mon, Feb 6, 2023 at 11:41 AM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > This seems like a question much better suited for the user mailing list to > see if any users actually use those formats. > > On Mon, Feb 6, 2023 at 12:26 PM Clebert Suconic > > wrote: > > > I wonder if anyone ever uses them? > > > > We used to make them because it was cool to do it years ago... now it > > feels like an useless step. > > > > Does anyone actually see value on them? > > > > On Mon, Feb 6, 2023 at 11:34 AM Justin Bertram > > wrote: > > > > > > Currently as part of the release process for Artemis we build docs in > > these > > > formats: > > > - HTML > > > - PDF > > > - EPUB > > > - MOBI > > > > > > I think we should only build docs in HTML and stop building them in > PDF, > > > EPUB, & MOBI. Building the extra formats adds a surprising overhead to > > the > > > release process, and I don't think they are useful enough to warrant > the > > > effort. > > > > > > Thoughts? > > > > > > > > > Justin > > > > > > > > -- > > Clebert Suconic > > >
[DISCUSS] discontinue PDF, EPUB, & MOBI docs for Artemis
Currently as part of the release process for Artemis we build docs in these formats: - HTML - PDF - EPUB - MOBI I think we should only build docs in HTML and stop building them in PDF, EPUB, & MOBI. Building the extra formats adds a surprising overhead to the release process, and I don't think they are useful enough to warrant the effort. Thoughts? Justin
Re: ASF Board Report
There's an ASF tool where you can add the release information [1] and that
information is then available to Bruce and he just copies and pastes it
into the report before he submits it. So the release process should include
using this tool.
Justin
[1] https://reporter.apache.org/addrelease.html?activemq
On Wed, Jan 18, 2023 at 11:15 AM Clebert Suconic
wrote:
> fine... we could start filling the draft as releases are done, as part
> of the release procedure?
>
> On Wed, Jan 18, 2023 at 10:39 AM Bruce Snyder
> wrote:
> >
> > I would rather employ the prepare-draft-in-site-git-repo approach because
> > it will result in a report format already prepared that can be
> copy/pasted
> > directly to Whimsy. I did not take steps to implement this approach as
> > there were some strong opinions about it previously. If we'd like to
> > utilize this approach, I'm all for it.
> >
> > Releases are already noted somewhere so they appear in the Whimsy stats
> > already.
> >
> > Bruce
> >
> > On Wed, Jan 18, 2023 at 9:21 AM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > Perhaps we should include a step in our release procedure to update
> some
> > > document on every release we make? Like quarter releases on our
> website
> > > so it’s always ready. (Which is most of what we do for the report )
> > >
> > > On Wed, Jan 18, 2023 at 4:58 AM Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > > wrote:
> > >
> > > > Are we dropping the prepare-draft-in-site-git-repo approach
> previously
> > > > discussed and put in place then used for the last report, and
> > > > switching entirely to email?
> > > >
> > > > I dont really mind which approach is used, as I said personally I
> just
> > > > use email elsewhere, but asking to know whether to delete the stale
> > > > file.
> > > >
> > > > Robbie
> > > >
> > > > On Wed, 18 Jan 2023 at 05:11, Bruce Snyder
> > > wrote:
> > > > >
> > > > > Please consider this message a call for contribution to the next
> board
> > > > > report!
> > > > >
> > > > > Kindly reply to this conversation with your contributions.
> > > > >
> > > > > Bruce
> > > > >
> > > > > On Tue, Jan 17, 2023 at 10:37 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Bruce,
> > > > > >
> > > > > > I think replying to a "call for report" email is OK.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > On Tue, Jan 17, 2023 at 5:27 PM Bruce Snyder <
> bruce.sny...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > I just realized that we were notified about our board report
> too
> > > > late to
> > > > > > > even submit the report as the meeting is scheduled to take
> place
> > > > > > tomorrow.
> > > > > > > So, let's plan on submitting it for next month's ASF board
> meeting.
> > > > > > >
> > > > > > > How do we want to go about gathering the board report
> contributions
> > > > for
> > > > > > > this and future reports? GitHub? Responses to this message?
> > > > > > >
> > > > > > > Bruce
> > > > > > >
> > > > > > > --
> > > > > > > perl -e 'print
> > > > > > >
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > );'
> > > > > > > http://bsnyder.org/
Re: Artemis tmp folder
You sent this same message [1] to the users mailing list, and I responded there already. Please don't send the same message to multiple mailing lists. Such duplicate messages wastes the time of the folks you are asking for support. Also, this list (i.e. the dev list) is for developers working directly on an ActiveMQ code-base. It's not for normal broker users. Justin [1] https://lists.apache.org/thread/wrlbvjpdtj6bvgz4kxcc1crblnps88sg On Fri, Jan 13, 2023 at 11:21 AM Matteo Bordin wrote: > Hello > in the Artemis documentation we find that it is better to delete the tmp > folder before start the artemis-node > Is it correct put in the Artemis start script the instruction "rm -r > tmp/*" ? > Or we have to remove only some file from the tmp artemis folder? > Thanks Matteo >
Re: Migrating ActiveMQ plugin to Artemis
Rony, your email seems to be completely unrelated to the rest of this
thread discussing plugin migration. Please start a new thread of your own
on the *users* list. Thanks!
Justin
On Thu, Jan 5, 2023 at 1:14 AM Rony Christian
wrote:
> Thanks for your reply.
>
> Currently I have connected to artemis (mqtt) but not able to connect with
> mqtts. I have attached here the current configuration (broker.xml).
>
>
>tcp://
>
> 0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true
>
>tcp://
>
> 0.0.0.0:8883?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass;protocols=MQTT
>
>
> name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass
>
>
> I'm using nodejs and here is my nodejs code to connect the mqtt server:
> this.username = 'myuname';
> this.password = 'mypass';
> this.endpoint = 'mqtt://my.endpoint.com;';
> this.options = {
> username: this.username,
> password: this.password,
> // ca: [fs.readFileSync(['/usr/share/ca-certificates/client.crt'])],
> rejectUnauthorized: false,
> protocol: "mqtts",
> port : 8883,
> // clientId: "mqttjs_" + new Date().getTime()
> // ssl: {
> // key: fs.readFileSync('./ssl/petpooja.pem'),
> // cert: fs.readFileSync('./ssl/STAR_petpooja_com.pem'),
> // },
> sslEnabled: true,
> trustStorePath: fs.readFileSync('./keystore.jks'),
> trustStorePassword: 'mypass',
> // keyStorePath: fs.readFileSync('./d/client-keystore.jks'),
> // keyStorePassword: 'securepass',
> };
>
> Can you please look into this, where I'm doing wrong?
>
> Thanks and Regards,
>
> On Thu, Jan 5, 2023 at 9:01 AM Justin Bertram wrote:
>
> > Can you elaborate on what exactly you haven't been able to translate into
> > Artemis' plugin architecture? As Gary mentioned, there's a fairly rich
> set
> > of integration points with the various plugins and the fact that the
> > security manager is pluggable as well. Examples of most of these are
> > shipped with the broker to help you get going. You shouldn't need to
> > implement your own JAAS login module as far as I can tell from your
> > description.
> >
> > That said, right now you'll have to jump through a few hoops to get
> details
> > from the SSL certificate into the authorization method as the
> > RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> > for additional discussion on that point.
> >
> > Ultimately there's no set of classes which will give you a 1 to 1
> > translation for migrating plugins since the internal broker architectures
> > are so different. However, the basic concepts should translate such that
> > just about anything you could do in "Classic" you should be able to do in
> > Artemis. If not, we'll implement those abilities where it makes sense.
> >
> >
> > Justin
> >
> > [1]
> >
> >
> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
> >
> > On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> > jedrzej.dudkiew...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I wrote to this group earlier
> > > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> > > and got a response regarding migrating plugin from AMQ to Artemis. But
> > > honestly even after reading links provided by Garry Tully I can't
> > > figure out how I should proceed. My plugin extends BrokerFilter
> > > (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> > > available methods: start(), addConnection(), removeConnection(),
> > > addConsumer(), removeConsumer(), addDestination(),
> > > addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> > > addProducer() and send().
> > >
> > > My first problem is that the first thing I want to do is to retrieve
> > > the certificate from connection (so probably getTransportConnection()
> > > from RemotingConnection in Artemis should be used?), parse it, read
> > > few fields and store proper information in SecurityContext associated
> > > with this connecti
Re: Migrating ActiveMQ plugin to Artemis
Can you elaborate on what exactly you haven't been able to translate into Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set of integration points with the various plugins and the fact that the security manager is pluggable as well. Examples of most of these are shipped with the broker to help you get going. You shouldn't need to implement your own JAAS login module as far as I can tell from your description. That said, right now you'll have to jump through a few hoops to get details from the SSL certificate into the authorization method as the RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2] for additional discussion on that point. Ultimately there's no set of classes which will give you a 1 to 1 translation for migrating plugins since the internal broker architectures are so different. However, the basic concepts should translate such that just about anything you could do in "Classic" you should be able to do in Artemis. If not, we'll implement those abilities where it makes sense. Justin [1] https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html [2] https://issues.apache.org/jira/browse/ARTEMIS-4059 On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz < jedrzej.dudkiew...@gmail.com> wrote: > Hello, > > I wrote to this group earlier > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html) > and got a response regarding migrating plugin from AMQ to Artemis. But > honestly even after reading links provided by Garry Tully I can't > figure out how I should proceed. My plugin extends BrokerFilter > (import org.apache.activemq.broker.BrokerFilter) and uses most/all > available methods: start(), addConnection(), removeConnection(), > addConsumer(), removeConsumer(), addDestination(), > addDestinationInfo(), removeDestination(), removeDestinationInfo(), > addProducer() and send(). > > My first problem is that the first thing I want to do is to retrieve > the certificate from connection (so probably getTransportConnection() > from RemotingConnection in Artemis should be used?), parse it, read > few fields and store proper information in SecurityContext associated > with this connection. Later this info is used to determine whether a > connected client can create, delete or send messages to specific > destinations (queues/topics?). Plugin also sends information about > connecting/disconnecting clients and so on to predefined queue. > > I tried to figure out how the JAAS plugin can be used for this, but > JAAS as a whole seems to be overly complicated and I'd rather > reimplement everything from scratch than try to figure out how to use > such umm... well regarded and mature solution. > > Is there some set of classes allowing for 1 to 1 translation of > ActiveMQ to Artemis plugins? > > TIA, > -- > Jędrzej Dudkiewicz > > I really hate this damn machine, I wish that they would sell it. > It never does just what I want, but only what I tell it. > >
Re: JsonUtil.truncate() unexpected behavior
As Robbie noted, this is expected. However, that doesn't mean it has to be that way. If you think it should be changed please open a Jira and outline a use-case where nulls make sense and empty strings don't. Justin On Wed, Nov 23, 2022 at 7:44 AM Robbie Gemmell wrote: > I guess its expected in so far as it was done deliberately: > https://github.com/apache/activemq-artemis/pull/3948 > > > On Wed, 23 Nov 2022 at 13:01, Jan Šmucr > wrote: > > > > Hello. > > > > I’ve been using the Message.toPropertyMap() function and recently I’ve > discovered that it does not preserve null values, as they get replaced by > an empty string in JsonUtil.truncate(). I understand that it’s not possible > to put null values into maps, but on the other hand, they are supported in > JSON and there’s quite a difference between null and "". And the > toPropertyMap function doc states clearly: “…useful when encoding to JSON”. > > > > Is this an expected behavior? I can work around that, but should I? > > > > Jan > > > >
[ANNOUNCE] ActiveMQ Artemis 2.27.0 Released
I'm pleased to announce the release of ActiveMQ Artemis 2.27.0. Downloads are now available at: https://activemq.apache.org/components/artemis/download/ For a complete list of updates: https://activemq.apache.org/components/artemis/download/release-notes-2.27.0 I would like to highlight these improvements: - Fix for CVE-2022-42889 (Apache Commons Text vulnerability) - Logging implementation moved to Apache Log4j 2 (internally using SLF4J) - New upgrade command to help users migrate from previous versions As usual it contains a handful of bug fixes and other improvements. Many thanks for all the contributors to this release. Justin
[RESULT] [VOTE] Apache ActiveMQ Artemis 2.27.0
Results of the Apache ActiveMQ Artemis 2.27.0 release vote. Vote passes with 8 binding votes. The following votes were received: Binding: +1 Justin Bertram +1 Robbie Gemmel +1 Tim Bish +1 Clebert Suconic +1 Jean-Baptiste Onofré +1 Domenico Francesco Bruscino +1 Krzysztof Porębski +1 Christpher Shannon Thank you to everyone who contributed and took the time to review the release candidates and vote. I'll update the website as soon as the CDN and Maven Central sync. Justin
[VOTE] Apache ActiveMQ Artemis 2.27.0
I would like to propose an Apache ActiveMQ Artemis 2.27.0 release. New and noteworthy items in 2.27.0: - Fix for CVE-2022-42889 (Apache Commons Text vulnerability) - Logging implementation moved to Apache Log4j 2 (internally using SLF4J) - New upgrade command to help users migrate from previous versions The release notes can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12352246 Ths git commit report is here: https://activemq.apache.org/components/artemis/download/commit-report-2.27.0 Source and binary distributions can be found here: https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.27.0/ The Maven repository is here: https://repository.apache.org/content/repositories/orgapacheactivemq-1265 In case you want to give it a try with the maven repo on examples: https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html The source tag: https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/2.27.0 I will update the website after the vote has passed. [ ] +1 approve this release [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here's my +1 Justin
Re: Scripts and Stuff WAS [HEADS UP] Artemis 2.27.0 next week
Awesome! Thanks, Clebert. Justin On Mon, Oct 31, 2022 at 8:54 AM Clebert Suconic wrote: > I will update the upgrade to be a real upgrade command. that is, to > read and replace things that matter, keeping any other customizations. > > > I will be done by tomorrow. > > On Sat, Oct 29, 2022 at 11:03 AM Clebert Suconic > wrote: > > > > We should actually review this before we release. > > > > > > our scripts in artemis are a bit messy. > > > > The idea of the artemis.profile was to be a single point o update > > between releases, but now variables and locations have spread into > > artemis, artemis.cmd, bootstrap.xml, jass-security-manager.. > > > > > > Is there a way we could clean this up so on future releases we only > > have to change the artemis.profile for a release? (mostly) > > > > > > if semantics have changed and we require a new setting is one thing.. > > .but anything about the instance and locations should be in the > > artemis.profile > > > > > > > > otherwise we just get rid of it, and place everything on artemis > > initial script itself. (if we can't have a single point anyway). > > > > > > > > > > > > > > > > > > > > On Fri, Oct 28, 2022 at 6:11 PM Clebert Suconic > > wrote: > > > > > > We should finish https://github.com/apache/activemq-artemis/pull/4246 > > > before we do a release. > > > > > > > > > We should probably update the upgrade nodes with the new ./artemis > > > upgrade command.. .which I will do next week... but I would appreciate > > > any feedback so we can finish it before we release. > > > > > > On Mon, Oct 24, 2022 at 4:36 PM Justin Bertram > wrote: > > > > > > > > I would like to put Artemis 2.27.0 up for vote next week mainly due > to > > > > CVE-2022-42889 [1] [2]. Please send any PRs you want in this release > ASAP. > > > > > > > > > > > > Justin > > > > > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2022-42889 > > > > [2] https://issues.apache.org/jira/browse/ARTEMIS-4060 > > > > > > > > > > > > -- > > > Clebert Suconic > > > > > > > > -- > > Clebert Suconic > > > > -- > Clebert Suconic > >
[HEADS UP] Artemis 2.27.0 next week
I would like to put Artemis 2.27.0 up for vote next week mainly due to CVE-2022-42889 [1] [2]. Please send any PRs you want in this release ASAP. Justin [1] https://nvd.nist.gov/vuln/detail/CVE-2022-42889 [2] https://issues.apache.org/jira/browse/ARTEMIS-4060
Re: [DISCUSS/VOTE] Remove Artemis Javadoc from the ActiveMQ website...
This got me thinking about who is the intended audience for the JavaDoc. It's not for folks working on the broker directly since they already have the source code and can read the JavaDoc directly. It's not for folks using JMS, AMQP, OpenWire, MQTT, or STOMP since the JavaDoc doesn't apply to any of those. From what I can tell, the JavaDoc is *only* for users leveraging the core client which is quite a small group and even those folks will almost certainly be using it in an IDE which can display it. I'm +1 to remove it, but if we do keep it then we should do something smarter like only publish it when something changes (e.g. methods are deprecated or added). Justin On Wed, Sep 28, 2022 at 11:18 AM Clebert Suconic wrote: > Can we stop publishing javadocs on the ActiveMQ Website for artemis? > > I see no point on publishing it as they are available in Maven. > > My vote is to completely remove it. > > > So, if you agree with me, please respond with > > +1 Yes, stop publishing javadocs for ActiveMQ Artemis on the website > and keep them on maven as usual. > > > > if you have any other preferences please state a -1 and a reason for.. > > > > -- > Clebert Suconic > >
Re: [VOTE] Apache ActiveMQ Artemis 2.26.0 release
I think that's fair. +1 Justin On Thu, Sep 22, 2022 at 2:58 PM Clebert Suconic wrote: > I am following up with an item that will be part of the document > upload on the release notes: > > https://github.com/apache/activemq-artemis/pull/4229 > > > > Rest as I said it's a maven dependency. There's no point in keeping it > as it can be accessed from a previous maven repository. > > > @Justin Bertram If you can move your vote to +1 based on this, I would > appreciate it.. but I think we are still proceeding with the release. > > > On Thu, Sep 22, 2022 at 3:49 PM Clebert Suconic > wrote: > > > > and it turns out activeMQ Artemis Rest is not part of the > > distribution... (I don't think it's ever been). > > > > it's a component that you consume from maven and you have to create > > your own war with your dependency. > > > > > > in these terms the current REST would work as is as long as you use it > > from a previous version... > > > > > > > > I will update the release notes with instructions on how to use Rest > > from a previous version. > > > > On Thu, Sep 22, 2022 at 3:16 PM Clebert Suconic > > wrote: > > > > > > The ActiveMQ Artemis Rest module itself is being pretty much > > > abandonware and no one wants to fix it... > > > > > > To fix it we would need to bring a few versions up to date.. and make > > > some improvements on the module. > > > > > > > > > > > > People can still use the Rest from any previous download of artemis. > > > Just bring the WAR from a previous version... > > > > > > > > > I will add a note on the release notes on how to do it... > > > > > > > > > > > > And I'm not against fixing it and keeping it.. as long as it become > > > active and fixed but I don't see anyone stepping up for it... > > > > > > > > > On Thu, Sep 22, 2022 at 2:57 PM Havret wrote: > > > > > > > > I may be a bit ignorant here (not a java dev), but how changing the > logging > > > > framework may justify and imply removing the whole functional module? > > > > > > > > On Thu, Sep 22, 2022 at 8:55 PM Clebert Suconic < > clebert.suco...@gmail.com> > > > > wrote: > > > > > > > > > We can put a release notes on how to bring the rest from a previous > > > > > version and still install in the current release... noticing this > > > > > won't be supported in future releases. > > > > > > > > > > > > > > > > > > > > And if you prefer to keep the module, just update the module and > bring > > > > > it back please. This release should progress I think. @Justin > would > > > > > you consider changing it to +1? > > > > > > > > > > On Thu, Sep 22, 2022 at 2:44 PM Clebert Suconic > > > > > wrote: > > > > > > > > > > > > if you want to keep that Rest, please fix it (update jboss-rest) > and > > > > > > then move it back. > > > > > > > > > > > > > > > > > > Especially we are removing jboss-logging, and that rest > implementation > > > > > > is strongly dependent on jboss-logging. > > > > > > > > > > > > On Thu, Sep 22, 2022 at 2:07 PM Justin Bertram < > jbert...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > -1 (binding) > > > > > > > > > > > > > > I just responded on the [DISCUSS] thread about removing the > REST > > > > > interface. > > > > > > > As far as I can tell the REST interface is perfectly > functional. I > > > > > think we > > > > > > > should deprecate it and update the documentation with an > explanation > > > > > before > > > > > > > removing it completely. > > > > > > > > > > > > > > > > > > > > > Justin > > > > > > > > > > > > > > On Wed, Sep 21, 2022 at 3:34 PM Clebert Suconic < > > > > > clebert.suco...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > I would like to propose an Apache ActiveMQ Artemis 2.26.0 > release. > > > > > > > > &g
Re: [VOTE] Apache ActiveMQ Artemis 2.26.0 release
-1 (binding) I just responded on the [DISCUSS] thread about removing the REST interface. As far as I can tell the REST interface is perfectly functional. I think we should deprecate it and update the documentation with an explanation before removing it completely. Justin On Wed, Sep 21, 2022 at 3:34 PM Clebert Suconic wrote: > I would like to propose an Apache ActiveMQ Artemis 2.26.0 release. > > > We removed ActiveMQ Artemis Rest, (which was already non functional) > as part of this release. > And other improvements and bug fixes. > > > The release notes can be found here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352297=12315920 > > Ths git commit report is here: > > https://activemq.apache.org/components/artemis/download/commit-report-2.26.0 > > Source and binary distributions: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.26.0 > > The Maven repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1262 > > > In case you want to give it a try with the maven repo on examples: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html > > The source tag is 2.26.0 on git, commit > 2d7b1a3ef7613dab68aeeb667f5b5eca37743b94: > https://github.com/apache/activemq-artemis/releases/tag/2.26.0 > > The source tag: > > https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/ > > > > I will update the website after the vote has passed. > > > [ ] +1 approve this release > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 Binding vote > > > > > -- > Clebert Suconic > >
Re: [DISCUSS] Removing Rest from ActiveMQ Artemis
I've been meaning to get to this for awhile. Better late than never, right? Generally speaking, I agree that REST is not a great fit for messaging. Whenever folks ask about it on the mailing lists, Slack, Stack Overflow, etc. I strongly encourage them for two main reasons: - The STOMP protocol is ubiquitous, simple, standardized, and can be used in almost every circumstance and environment where REST might be used. - REST is not portable because there's no standard messaging interface for REST. This is generally bad for users as it locks them in to a specific broker. Here are a few additional reasons: - For simple use-cases (e.g. basic send & receive) it's easy these days to create your own REST interface and then implement messaging behind that. Since the REST interface is in the user's control portability isn't an issue. - It's a bit of a pain to setup as it requires manually building a WAR file. That said, it **is functional**. All the REST tests in the test-suite are passing, and I just ran through the documentation and tested it on a fresh install of 2.25.0. Everything works as far as I can tell. Although I don't think anybody wants to invest the resources to bring all the dependencies up-to-date. Also, I think we should deprecate it and update the documentation with an explanation before we completely remove it. Justin On Thu, Sep 8, 2022 at 9:04 AM Clebert Suconic wrote: > I'm not sure if there's much to discuss here. Rest in Artemis has been > abandonware for a while (like 5 years)... The jboss-rest interface is > a few major releases behind, the module compiles but it's not > functional, and any time someone ask questions we just mention don't > use it... (favoring stomp instead). > > > https://github.com/apache/activemq-artemis/tree/main/artemis-rest > > > As part of new logging changes, we are moving activemq-artemis into 3.0... > > At this point I see no other choice than remove the module. > > Any objections? > > -- > Clebert Suconic > >
Re: HEADS-UP 2.25.1 Next week
In my opinion there is a bit of more work to do before 3.0 could be released. For example: - Remove all deprecated methods, config, etc. (this is not a small amount of work) - Update all the config with the new inclusive terms Personally I don't really see how we could do the logging change on 2.x as it's a breaking change. Folks won't be able to follow the normal upgrade procedure [1] since it will break their logging configuration. I also think that anything we want to remove in 3.0 should be deprecated for at least 1 release of 2.x. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/upgrading.html On Fri, Sep 16, 2022 at 8:43 AM Clebert Suconic wrote: > hmmm... this is actually pointless.. (the 2.x branch so far). > > > I had to cherry-pick *everything* except to 1 commit: > > ARTEMIS-3987Removing ActiveMQ Artemis Rest from the codebase - commit > e654eba > > > > We could definitely release from main right now... > > > and I'm wondering if we shouldn't make the logging change on a 2.x > branch I don't see much else beyond logging to warrant a 3.x > branch (we can certainly make a plan for a 3.x and we could / should > start working on it). > > > What do you think? > > On Thu, Sep 15, 2022 at 4:41 PM Clebert Suconic > wrote: > > > > @Gary Tully unless you don't consider removing activemq-rest and > > changing the logging framework a change big enough to warrant a bump > > to 3.0. if the consensus is to keep main as 2.x we can certainly > > rename it back and do the release from main. I thought we should > > rename it based on these two things. > > > > On Thu, Sep 15, 2022 at 11:22 AM Clebert Suconic > > wrote: > > > > > > maini is already 3.0... removed Rest, and soon the logging change will > > > be put it in there... If I release from main now, it will be called > > > 3.0, and we will have to do a 4.0 when we bring in the logging > > > changes. > > > > > > > > > So, I would rather cherry-pick stuff into 2.x > > > > > > (I will go ahead and remove 2.25.x now) > > > > > > On Thu, Sep 15, 2022 at 8:46 AM Gary Tully > wrote: > > > > > > > > would it make sense to just cut 2.26.0 from main? > > > > > > > > On Wed, 14 Sept 2022 at 02:11, Clebert Suconic > > > > wrote: > > > > > > > > > > I am renaming the branch as 2.x (instead of 2.25.x). > > > > > > > > > > > > > > > Some of the candidates to cherry-pick categorize it as an > enhancement, > > > > > so it would make the release next week to be named 2.26.0 instead > of > > > > > 2.25.1) (same branch, just promoting it to 2.26 due to an > enhancement > > > > > being part of it). > > > > > > > > > > for that reason I am pushing a 2.x branch and I will remove the > 2.25.x > > > > > branch (after a few days). > > > > > > > > > > On Tue, Sep 13, 2022 at 11:40 AM Clebert Suconic > > > > > wrote: > > > > > > > > > > > > I would like to do a 2.25.1 next week (monday or tuesday). > > > > > > > > > > > > > > > > > > Please add any commits into 2.25.x (just pushed a new branch)... > > > > > > > > > > > > > > > > > > please use cherry-pick -x on commits from main only. (git > cherry-pick > > > > > > -x ) > > > > > > > > > > > > -- > > > > > > Clebert Suconic > > > > > > > > > > > > > > > > > > > > -- > > > > > Clebert Suconic > > > > > > > > > > > > -- > > > Clebert Suconic > > > > > > > > -- > > Clebert Suconic > > > > -- > Clebert Suconic > >
Re: [VOTE] ActiveMQ Artemis 2.25.0 Release
+1 (binding) Justin On Wed, Aug 31, 2022 at 11:38 AM Clebert Suconic wrote: > I would like to propose an Apache ActiveMQ Artemis 2.25.0 release. > > This JIRA improved flow control from paging preventing Out Of Memory > issues when there's a bad consumer without flow control (ARTEMIS-3943 > (Thank you Anton Roskvist)). > > Among other fixes and improvements. > > > The whole release notes could be found here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352143=12315920 > > > The commit report: > > https://activemq.apache.org/components/artemis/download/commit-report-2.25.0 > > Source and binary distributions can be found here: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.25.0 > > The Maven repository is here: > > https://repository.apache.org/content/repositories/orgapacheactivemq-1261 > > > In case you want to give it a try with the maven repo on examples: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html > > > The source tag: > > > https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=commit;h=fb1b362b473cad51ae5d05a897be02b1fa8461d4 > > The tag is 2.25.0 on git. > > > I will update the website after the vote has passed. > > > [ ] +1 approve the release as Apache Artemis 2.4.0 > [ ] -1 disapprove (and reason why) > > > Here's my +1 Binding > >
Re: Issue masking LDAP password in login.config
Any feedback here? Did your user get this sorted out? Justin On Tue, Aug 16, 2022 at 11:51 AM Justin Bertram wrote: > > ...is there any other known restriction to masking passwords that might > not be obvious or well documented? > > I'm not aware of any restrictions for masked passwords. If it can be put > into a Java String then it can be masked and unmasked. The default masking > & unmasking algorithms work directly with byte[] so there's no real > restrictions. > > The "artemis mask" command spits out the masked password, but it still > needs to be wrapped in "ENC()" to be detected properly in login.config. In > the other thread I pasted a link to the ActiveMQ Artemis test-suite which > demonstrates how to configure the password. Is the user doing this properly? > > > Justin > > On Tue, Aug 16, 2022 at 10:53 AM Andrew Pomponio > wrote: > >> Hello Artemis Devs, >> I originally opened a ticket with the users mailing list to discuss the >> following issue: >> https://lists.apache.org/thread/6ptmpln9wfysv07v3ncdxkd2c99glh9t >> >> TL:DR: a user is attempting to mask their password in login.config and >> when they attempt to authenticate against LDAP, they get an authentication >> error. >> >> We’ve reviewed the idea that they could be using a password with >> unsupported characters and spaces, but we’re attempting to explore other >> options as well. Artemis is logging the following error: >> 2022-07-19 11:26:08,144 ERROR [org.apache.activemq.artemis.core.server] >> AMQ224084: Failed to open context: javax.naming.AuthenticationException: >> [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090439, comment: >> AcceptSecurityContext error, data 52e, v4563�] >> >> Aside from the special characters and spaces theory, is there any other >> known restriction to masking passwords that might not be obvious or well >> documented? They have tested the password in plaintext so it does work that >> way, it’s just the masking of it that does not work. If it matters at all, >> the user is using pre-built container images for artemis that run on Debian >> 10 and Java 11. We’re attempting to get debug logs for >> org.apache.activemq.artemis.spi.core.security.jaas from the user, and we’ve >> also sent them our own working example main.java file to demonstrate to >> them how password masking “should” work. The purpose of this was to make >> sure the password is hardcoded in the main.java file and matches the output >> of a java code snippet. We are also attempting to verify if they’re >> implementing TLS over LDAP as well to see if that’s adding any overhead >> complications. Any additional insight is greatly appreciated. Thanks! >> >> >> >> >> >> This e-mail may contain information that is privileged or confidential. >> If you are not the intended recipient, please delete the e-mail and any >> attachments and notify us immediately. >> >>
Re: [HEADS-UP] ActiveMQ Artemis 2.25.0 release
I need to deal with ARTEMIS-3958 [1]. I should send a PR today. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-3958 On Mon, Aug 22, 2022 at 5:18 PM Clebert Suconic wrote: > I'm considering cutting a 2.25.0 release this Wed. Any upgrades we > must do before? any PRs we mush finish before releasing it? > > -- > Clebert Suconic > >
CVE-2022-35278: Apache ActiveMQ Artemis: HTML Injection in ActiveMQ Artemis Web Console
Description: An attacker could show malicious content and/or redirect users to a malicious URL in the web console by using HTML in the name of an address or queue. Mitigation: Upgrade to Apache ActiveMQ Artemis 2.24.0. Credit: Apache ActiveMQ would like to thank Yash Pandya (Digital14), Rajatkumar Karmarkar (Digital14), and Likhith Cheekatipalle (Digital14) for reporting this issue.
Re: Issue masking LDAP password in login.config
> ...is there any other known restriction to masking passwords that might not be obvious or well documented? I'm not aware of any restrictions for masked passwords. If it can be put into a Java String then it can be masked and unmasked. The default masking & unmasking algorithms work directly with byte[] so there's no real restrictions. The "artemis mask" command spits out the masked password, but it still needs to be wrapped in "ENC()" to be detected properly in login.config. In the other thread I pasted a link to the ActiveMQ Artemis test-suite which demonstrates how to configure the password. Is the user doing this properly? Justin On Tue, Aug 16, 2022 at 10:53 AM Andrew Pomponio wrote: > Hello Artemis Devs, > I originally opened a ticket with the users mailing list to discuss the > following issue: > https://lists.apache.org/thread/6ptmpln9wfysv07v3ncdxkd2c99glh9t > > TL:DR: a user is attempting to mask their password in login.config and > when they attempt to authenticate against LDAP, they get an authentication > error. > > We’ve reviewed the idea that they could be using a password with > unsupported characters and spaces, but we’re attempting to explore other > options as well. Artemis is logging the following error: > 2022-07-19 11:26:08,144 ERROR [org.apache.activemq.artemis.core.server] > AMQ224084: Failed to open context: javax.naming.AuthenticationException: > [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090439, comment: > AcceptSecurityContext error, data 52e, v4563�] > > Aside from the special characters and spaces theory, is there any other > known restriction to masking passwords that might not be obvious or well > documented? They have tested the password in plaintext so it does work that > way, it’s just the masking of it that does not work. If it matters at all, > the user is using pre-built container images for artemis that run on Debian > 10 and Java 11. We’re attempting to get debug logs for > org.apache.activemq.artemis.spi.core.security.jaas from the user, and we’ve > also sent them our own working example main.java file to demonstrate to > them how password masking “should” work. The purpose of this was to make > sure the password is hardcoded in the main.java file and matches the output > of a java code snippet. We are also attempting to verify if they’re > implementing TLS over LDAP as well to see if that’s adding any overhead > complications. Any additional insight is greatly appreciated. Thanks! > > > > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > >
Re: [PROPOSAL] Completely remove Camel reference in the ActiveMQ broker
+1 Justin On Thu, Aug 4, 2022 at 2:10 AM Jean-Baptiste Onofré wrote: > Hi, > > We already removed the activemq-camel component from ActiveMQ distribution. > > However, we still have references to Camel in ActiveMQ distribution > (in the conf example, in the shipped libraries, ...). > > For ActiveMQ 5.18.x, I propose to completely remove any reference to Camel. > > No objection ? > > Regards > JB > >
Re: Support PROXY protocol for Acceptors
I'm not a Netty expert by any means, but I would start in org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor. That's where most of the Netty pipeline is configured, and it's also where the main org.apache.activemq.artemis.core.protocol.ProtocolHandler.ProtocolDecoder is added. Justin On Sat, Jul 30, 2022 at 11:40 AM Working Titus wrote: > Hey Justin, > > So yeah! I would be thrilled to contribute with this one myself, but the > project is quite big and I'm a bit unsure about where to start, could you > maybe give me some directions? Should I create a Jira issue at Artemis Jira > to follow up with the work? > > Greetings, > João Santos > > On Wed, Jul 27, 2022 at 9:11 PM Justin Bertram > wrote: > > > ActiveMQ Artemis doesn't support the PROXY protocol, but it looks > > interesting and I think it would be worth implementing. Is this something > > you'd want to contribute? I see that Netty already has support for this > [1] > > so most of the heavy lifting has already been done. > > > > > > Justin > > > > [1] https://github.com/netty/netty/tree/4.1/codec-haproxy > > > > On Wed, Jul 27, 2022 at 3:46 AM Working Titus > > wrote: > > > > > Hey guys! > > > > > > I've just installed and configured an ActiveMQ Artemis 2.23.0 Cluster > and > > > was looking to use HAProxy as a Load Balancer for the STOMP > connections, > > in > > > order to avoid a client-side load balancing configuration. > > > > > > I was successful in implementing it, however I was unable to set it up > > > using PROXY protocol an so all the client IP addresses in the Artemis > Web > > > Console appear as the Load Balancer's IP address. > > > > > > Is there any configuration I can add to the Acceptors so they work with > > > PROXY protocol or is it just not supported? And if so, would it be > > possible > > > to implement this support, or is it just something not > > wanted/interesting? > > > > > > Best regards, > > > João Santos > > > > > >
Re: [VOTE] Apache ActiveMQ Artemis 2.24.0
+1 (binding) Justin On Tue, Jul 26, 2022 at 1:38 PM Clebert Suconic wrote: > I would like to propose an Apache ActiveMQ Artemis 2.24.0 release > > There are two features added as part of this release: > > - Paging does not use soft cache any longer. As a matter of fact we > don't have any caching now.. we just read from files straight to > Queues > - Mirror now supports encryption of password > > and several fixes, mainly in AMQP Mirroring > > Thanks for all the contributions on this release! > > > > The release notes is here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351822=12315920 > > > The git commit report is here: > > https://activemq.apache.org/components/artemis/download/commit-report-2.24.0 > > > > Source and binary distributions can be found here: > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.24.0 > > > The Maven repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1259 > > > In case you want to give it a try with the maven repo on examples: > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html > > > The source tag: > https://github.com/apache/activemq-artemis/releases/tag/2.24.0 > > > I will update the website after the vote has passed. > > > [ ] +1 approve this release > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > Here's my +1 Binding > > > > > > -- > Clebert Suconic > >
Re: Support PROXY protocol for Acceptors
ActiveMQ Artemis doesn't support the PROXY protocol, but it looks interesting and I think it would be worth implementing. Is this something you'd want to contribute? I see that Netty already has support for this [1] so most of the heavy lifting has already been done. Justin [1] https://github.com/netty/netty/tree/4.1/codec-haproxy On Wed, Jul 27, 2022 at 3:46 AM Working Titus wrote: > Hey guys! > > I've just installed and configured an ActiveMQ Artemis 2.23.0 Cluster and > was looking to use HAProxy as a Load Balancer for the STOMP connections, in > order to avoid a client-side load balancing configuration. > > I was successful in implementing it, however I was unable to set it up > using PROXY protocol an so all the client IP addresses in the Artemis Web > Console appear as the Load Balancer's IP address. > > Is there any configuration I can add to the Acceptors so they work with > PROXY protocol or is it just not supported? And if so, would it be possible > to implement this support, or is it just something not wanted/interesting? > > Best regards, > João Santos >
Re: [DISCUSS] Remove shaded client JARS
To be clear, the documentation already exists [1]. It just needs to be updated with the aforementioned details when the uber jars are removed. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic wrote: > sure, of course we need to update the docs in relation to anything > these removed jars. What I meant was we need to document the jars that > are required independently of removing the jars.. if someone wants to > use the client jars the client dependency should be documented anyway. > that's what I meant > > On Tue, Jul 26, 2022 at 3:25 PM Justin Bertram > wrote: > > > > I'm not sure what you mean by "independent issue." If we remove the uber > > jars then the docs have to be updated. The two things are directly > related, > > right? > > > > > > Justin > > > > On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic < > clebert.suco...@gmail.com> > > wrote: > > > > > I think that’s an independent issue. The doc would need to be updated > > > anyways. > > > > > > On Tue, Jul 26, 2022 at 2:40 PM Justin Bertram > > > wrote: > > > > > > > Yes, the documentation needs to be clear. This is a usability issue. > > > > > > > > Even if you did a "mvn dependency:list" you'd get a list including > > > optional > > > > and test dependencies. Also, there would be potentially unnecessary > > > > dependencies (e.g. netty-transport-native-kqueue even if you aren't > on a > > > > Mac). > > > > > > > > > > > > Justin > > > > > > > > On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic < > > > clebert.suco...@gmail.com > > > > > > > > > wrote: > > > > > > > > > the pom on artemis-core-client, artemis-jms-client, and > > > > > artemis-jakarta-client... They will include all the needed > > > > > dependencies, right? > > > > > > > > > > > > > > > what is the issue? to have a clear text on the docs? > > > > > > > > > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram < > jbert...@apache.org> > > > > > wrote: > > > > > > > > > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue > > > there > > > > > was > > > > > > that it wasn't clear what jars were needed on the client. If we > > > remove > > > > > the > > > > > > uber jars then we need to update the documentation to make > crystal > > > > clear > > > > > > what jars are needed on the client, including details about what > jars > > > > may > > > > > > be optional depending on which functionality the client uses. > > > > > > > > > > > > I'm not necessarily against it, but removing the uber jar is > probably > > > > > going > > > > > > to sting for a handful of users. Anything we can do to alleviate > that > > > > > will > > > > > > help. Maybe we could generate a text file in lib/client instead > of > > > the > > > > > uber > > > > > > jars to help users who expect them to be there. The text could > list > > > the > > > > > > jars required for the client's classpath. > > > > > > > > > > > > > > > > > > Justin > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129 > > > > > > > > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic < > > > > > clebert.suco...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > We currently deploy these following shaded uber jars with > ActiveMQ > > > > > Artemis. > > > > > > > > > > > > > > artemis-jms-client-all > > > > > > > artemis-core-client-all > > > > > > > artemis-jakarta-client-all > > > > > > > > > > > > > > We are in the process of removing jboss-logging, and replacing > it > > > by > > > > > > > SLF4j /LOG4J on a separate branch, and we will probably make a > > > switch > > > > > > > on the branch as 3.0. >
Re: [DISCUSS] Remove shaded client JARS
I'm not sure what you mean by "independent issue." If we remove the uber jars then the docs have to be updated. The two things are directly related, right? Justin On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic wrote: > I think that’s an independent issue. The doc would need to be updated > anyways. > > On Tue, Jul 26, 2022 at 2:40 PM Justin Bertram > wrote: > > > Yes, the documentation needs to be clear. This is a usability issue. > > > > Even if you did a "mvn dependency:list" you'd get a list including > optional > > and test dependencies. Also, there would be potentially unnecessary > > dependencies (e.g. netty-transport-native-kqueue even if you aren't on a > > Mac). > > > > > > Justin > > > > On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic < > clebert.suco...@gmail.com > > > > > wrote: > > > > > the pom on artemis-core-client, artemis-jms-client, and > > > artemis-jakarta-client... They will include all the needed > > > dependencies, right? > > > > > > > > > what is the issue? to have a clear text on the docs? > > > > > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram > > > wrote: > > > > > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue > there > > > was > > > > that it wasn't clear what jars were needed on the client. If we > remove > > > the > > > > uber jars then we need to update the documentation to make crystal > > clear > > > > what jars are needed on the client, including details about what jars > > may > > > > be optional depending on which functionality the client uses. > > > > > > > > I'm not necessarily against it, but removing the uber jar is probably > > > going > > > > to sting for a handful of users. Anything we can do to alleviate that > > > will > > > > help. Maybe we could generate a text file in lib/client instead of > the > > > uber > > > > jars to help users who expect them to be there. The text could list > the > > > > jars required for the client's classpath. > > > > > > > > > > > > Justin > > > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129 > > > > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic < > > > clebert.suco...@gmail.com> > > > > wrote: > > > > > > > > > We currently deploy these following shaded uber jars with ActiveMQ > > > Artemis. > > > > > > > > > > artemis-jms-client-all > > > > > artemis-core-client-all > > > > > artemis-jakarta-client-all > > > > > > > > > > We are in the process of removing jboss-logging, and replacing it > by > > > > > SLF4j /LOG4J on a separate branch, and we will probably make a > switch > > > > > on the branch as 3.0. > > > > > > > > > > I never really liked these shaded jars as part of the > distribution. I > > > > > would be inclined to remove them on a switch for 3.0 anyways, and > now > > > > > we are having a build issue, > > > > > as they will fail (on a second build) shading > apache-commons-logging: > > > > > > > > > > ERROR] Failed to execute goal > > > > > org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade (default) > on > > > > > project artemis-core-client-all: Error creating shaded jar: > duplicate > > > > > entry: META-INF/services/org.apache.activemq.artemis.shaded.org > > > > > .apache.commons.logging.LogFactory > > > > > -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the > > > > > errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using > > > > > the -X switch to enable full debug logging. [ERROR] [ERROR] For > more > > > > > information about the errors and possible solutions, please read > the > > > > > following articles: [ERROR] [Help 1] > > > > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > > > > [ERROR] [ERROR] After correcting the problems, you can resume the > > > > > build with the command [ERROR] mvn -rf > > > > > :artemis-core-client-all > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Remove shaded client JARS
Yes, the documentation needs to be clear. This is a usability issue. Even if you did a "mvn dependency:list" you'd get a list including optional and test dependencies. Also, there would be potentially unnecessary dependencies (e.g. netty-transport-native-kqueue even if you aren't on a Mac). Justin On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic wrote: > the pom on artemis-core-client, artemis-jms-client, and > artemis-jakarta-client... They will include all the needed > dependencies, right? > > > what is the issue? to have a clear text on the docs? > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram > wrote: > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue there > was > > that it wasn't clear what jars were needed on the client. If we remove > the > > uber jars then we need to update the documentation to make crystal clear > > what jars are needed on the client, including details about what jars may > > be optional depending on which functionality the client uses. > > > > I'm not necessarily against it, but removing the uber jar is probably > going > > to sting for a handful of users. Anything we can do to alleviate that > will > > help. Maybe we could generate a text file in lib/client instead of the > uber > > jars to help users who expect them to be there. The text could list the > > jars required for the client's classpath. > > > > > > Justin > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129 > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic < > clebert.suco...@gmail.com> > > wrote: > > > > > We currently deploy these following shaded uber jars with ActiveMQ > Artemis. > > > > > > artemis-jms-client-all > > > artemis-core-client-all > > > artemis-jakarta-client-all > > > > > > We are in the process of removing jboss-logging, and replacing it by > > > SLF4j /LOG4J on a separate branch, and we will probably make a switch > > > on the branch as 3.0. > > > > > > I never really liked these shaded jars as part of the distribution. I > > > would be inclined to remove them on a switch for 3.0 anyways, and now > > > we are having a build issue, > > > as they will fail (on a second build) shading apache-commons-logging: > > > > > > ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade (default) on > > > project artemis-core-client-all: Error creating shaded jar: duplicate > > > entry: META-INF/services/org.apache.activemq.artemis.shaded.org > > > .apache.commons.logging.LogFactory > > > -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the > > > errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using > > > the -X switch to enable full debug logging. [ERROR] [ERROR] For more > > > information about the errors and possible solutions, please read the > > > following articles: [ERROR] [Help 1] > > > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > > [ERROR] [ERROR] After correcting the problems, you can resume the > > > build with the command [ERROR] mvn -rf > > > :artemis-core-client-all > > > > > > > > > > > > > > > Also, they add about 20MB to our distribution, and more 10MB for the > > > core-client-all that's not on the distro but it is on maven repo. > > > > > > This is a common trend with other projects. Netty stopped producing a > > > netty-all and is offering a pom. Jetty did the same thing.. and There > > > are a lot of issues introduced by an "all client". > > > > > > > > > So, even though we could fix the build, these JARs are never tested as > > > part of the testsuite or anything It's like playing with the > > > odds... and they are huge on the distribution as they will all > > > include copies of Netty. > > > > > > > > > I would really like to remove these JARs and I think it would be a > > > great improvement to do so. > > > > > > These POMS are already defining all the dependencies anyway. Any user > > > who wants to have a shaded jar would just be able to shade it > > > themselves as part of their project. > > > > > > > > > If anyone have a strong feeling about keeping them we would need: > > > > > > - your opinion (why we keep them on 3.0) > > > - Help fixing the build on new-logging > > > - Help with adding smoke tests for these jars. > > > > > > > > > anyone? > > > > > > > > > > -- > Clebert Suconic > >
Re: [DISCUSS] Remove shaded client JARS
The original impetus for the uber jar was ARTEMIS-1129. The issue there was that it wasn't clear what jars were needed on the client. If we remove the uber jars then we need to update the documentation to make crystal clear what jars are needed on the client, including details about what jars may be optional depending on which functionality the client uses. I'm not necessarily against it, but removing the uber jar is probably going to sting for a handful of users. Anything we can do to alleviate that will help. Maybe we could generate a text file in lib/client instead of the uber jars to help users who expect them to be there. The text could list the jars required for the client's classpath. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-1129 On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic wrote: > We currently deploy these following shaded uber jars with ActiveMQ Artemis. > > artemis-jms-client-all > artemis-core-client-all > artemis-jakarta-client-all > > We are in the process of removing jboss-logging, and replacing it by > SLF4j /LOG4J on a separate branch, and we will probably make a switch > on the branch as 3.0. > > I never really liked these shaded jars as part of the distribution. I > would be inclined to remove them on a switch for 3.0 anyways, and now > we are having a build issue, > as they will fail (on a second build) shading apache-commons-logging: > > ERROR] Failed to execute goal > org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade (default) on > project artemis-core-client-all: Error creating shaded jar: duplicate > entry: META-INF/services/org.apache.activemq.artemis.shaded.org > .apache.commons.logging.LogFactory > -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the > errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using > the -X switch to enable full debug logging. [ERROR] [ERROR] For more > information about the errors and possible solutions, please read the > following articles: [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] [ERROR] After correcting the problems, you can resume the > build with the command [ERROR] mvn -rf > :artemis-core-client-all > > > > > Also, they add about 20MB to our distribution, and more 10MB for the > core-client-all that's not on the distro but it is on maven repo. > > This is a common trend with other projects. Netty stopped producing a > netty-all and is offering a pom. Jetty did the same thing.. and There > are a lot of issues introduced by an "all client". > > > So, even though we could fix the build, these JARs are never tested as > part of the testsuite or anything It's like playing with the > odds... and they are huge on the distribution as they will all > include copies of Netty. > > > I would really like to remove these JARs and I think it would be a > great improvement to do so. > > These POMS are already defining all the dependencies anyway. Any user > who wants to have a shaded jar would just be able to shade it > themselves as part of their project. > > > If anyone have a strong feeling about keeping them we would need: > > - your opinion (why we keep them on 3.0) > - Help fixing the build on new-logging > - Help with adding smoke tests for these jars. > > > anyone? > >
Re: [VOTE] ActiveMQ Artemis Native 2.0.0 release (RC2)
+1 Nice work guys! Justin On Tue, Jul 12, 2022 at 2:59 PM Clebert Suconic wrote: > I would like to propose an ActiveMQ Artemis Native 2.0.0 release > > > For those who are not familiar, this is the Native Layer in Artemis > responsible for the integration on Linux and Libaio. > > > I have been working on some logging changes with Robbie Gemmel, and > Artemis Native 2.0.0 is now using SLF4J. This Module will be a > requirement for ActiveMQ Artemis to move forward with SLF4J. > > > > The source distribution is here: > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/2.0.0/ > > > The Maven staged repository is here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1257 > > > The git tag is here: > https://github.com/apache/activemq-artemis-native/releases/tag/2.0.0 > > > the release notes is here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348395 > > > > > [ ] +1 approve this release > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > Here's my +1 binding > > > > > -- > Clebert Suconic > >
