Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis
I will push a temporary branch into gitbox.apache.org/repos/asf/activemq-artemis.git named new-logging This branch will be later removed and all the commits squashed accordingly before we push a change into main. This is just to make it easier for multiple people to work on the same branch while we are working on this. I don't mind much about the commit messages at this point as they are all going to be squashed... On Sat, May 7, 2022 at 12:24 AM Michael André Pearce wrote: > > +1 for switching to slf4j > > My only one and main comment will be that it is essential that the out the > box configuration should result in the same log formats and codes as today, > as I know many rely on log format parsing and rules for alerting, so to be > non breaking change the log output should be identical. > > Sent from my iPad > > > On 4 May 2022, at 18:27, Arthur Naseef wrote: > > > > +1 on SLF4J - that's what it does: eliminate the tight coupling of code > > generating log output from the logging implementation. > > > > For testing, I would just make the logger injectable, but configure a > > default. Here's a "Live Template" for intellij that does this (minus the > > getter and setter): > > > > private static final org.slf4j.Logger DEFAULT_LOGGER = > > org.slf4j.LoggerFactory.getLogger($CLASS$.class); > > > > > > private org.slf4j.Logger log = DEFAULT_LOGGER; > > > > > > Cheers! > > > > Art > > > > > >> On Wed, May 4, 2022 at 8:15 AM Matt Pavlovich wrote: > >> > >> Hey Clebert- > >> > >> We just did this as part of log4j2 conversion. Here is a sample test > >> class w/ in-line appender: > >> > >> > >> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java > >> < > >> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java > >>> > >> > >> Matt Pavlovich > >> > >>> On May 4, 2022, at 7:37 AM, Clebert Suconic > >> wrote: > >>> > >>> A few questions I have: > >>> > >>> - One of things we do in the testsuite is to capture loggers with an > >>> interceptor and assert the loggers were called. How would we do such a > >>> thing? an appender? Can someone point me to a test in ActiveMQ5 doing > >>> that? > >>> > >>> - how would you configure Log4J? (assuming we are using log4j with SLF4j) > >>> > >>> - also we have separate loggers for Auditing... I think that will be > >>> just an entry on the log4j configuration. > >>> > >>> On Wed, May 4, 2022 at 8:16 AM Clebert Suconic > >>> wrote: > > MDC seems nice, but I don't think it's relevant here.. we need the > Codes as part of the messages where they appear. Some users will > create alerts for them on their log frameworks. > > On Wed, May 4, 2022 at 1:16 AM Christoph Läubrich > >> wrote: > > > > SLF4J support the "Mapped Diagnostic Context" > > > > maybe this would be a good replacement here? you could even add more > > context infos then and people are free to format them as they like: > > > > https://logback.qos.ch/manual/mdc.html > > > > Am 03.05.22 um 22:30 schrieb Justin Bertram: > >> The point here is that the current logging implementation provides a > >> simple > >> way to associate codes with each user-facing log message and > >> exception. > >> This is helpful to those who may want to monitor logs for certain > >> codes > >> (e.g. for alerting purposes), filter some codes out, etc. In this way > >> the > >> logging is part of a contract with the users much like an API is a > >> contract > >> with developers. The codes stay consistent across versions but the > >> content > >> of the message may change (e.g. to provide more information, correct > >> spelling errors, typos, etc.). This kind of facade also opens the > >> door for > >> fairly simple internationalization. > >> > >> The goals here as I see them: > >> - Maintain the aforementioned functionality. > >> - Ditch the dependence on JBoss Log Manager and JBoss Logging. > >> > >> Having a simple implementation of our own is an easy way to do this. > >> If we > >> decide to go this route then (and only then) we will need to decide > >> on the > >> underlying logging facade and implementation. > >> > >> > >> Justin > >> > >> > >> On Tue, May 3, 2022 at 3:17 PM Christopher Shannon < > >> christopher.l.shan...@gmail.com> wrote: > >> > >>> Using SL4J makes sense to me as that is what almost everyone else > >> uses so > >>> it's pretty standard and easy to swap implementations > >>> > >>> On Mon, May 2, 2022 at 1:26 PM Justin Bertram > >> wrote: > >>> > I think this looks great, Clebert. The code is straightforward, and > >> I > >>> like > the idea of reducing our dependencies. >
Re: Using JSON-B in ActiveMQ
When I originally posted, my hope was that Jackson might be able to implement JSON-B itself. Almost a year on, that feels like it would still be my favourite approach, but is possibly not realistic. Would the community be open to an abstraction in ActiveMQ allowing either Jackson, or a JSON-B implementation to be used? I'm thinking along the lines of JAX-RS' MessageBodyReader / MessageBodyWriter - this could be interesting as there has been a proposal to use it for handling JSON-based messages in Jakarta Messaging: https://github.com/jakartaee/messaging-proposals/tree/master/jsonb-messages/proposal1 The thought here would be to have two implementations of MessageBodyReader/MessageBodyWriter (one for Jackson - the default), one that delegates to JSON-B), and use whichever is configured. It looks like there are a few places we'd need to do this: * DestinationsViewFilter * PartitionBrokerPlugin * ZooKeeperPartitionBroker * Partition & Target classes * PersistenceAdapterView Does that list sound right, or is there functionality I'm missing in that list? Does the abstraction sound reasonable, or would you not be in favor? Thanks Jon On Tue, Feb 2, 2021 at 11:38 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > Thanks for the feedback - I'll look at this targeting 5.17! > > Jon > > On Thu, Jan 28, 2021 at 6:32 PM Matt Pavlovich wrote: > >> +1 JSON-B using Jackson and targeting 5.17.x >> >> Given the popularity of pairing ActiveMQ w/ Camel and CXF, I think >> staying with Jackson is a good idea and would cause less volatility. >> >> > On Jan 28, 2021, at 5:36 AM, Jean-Baptiste Onofre >> wrote: >> > >> > Hi Jon, >> > >> > Clearly +1 for me to go using JSON-B. >> > >> > However, I will focus this for 5.17.x. I’m working on cleanup, update, >> etc for this version, so I think it’s the good timing to use JSON-B. >> > >> > So, +1 to use master (5.17.x) for that. If you can wait a bit, I can >> merge the first round cleanup (removing leveled, etc). >> > Else, go ahead, we will rebase. >> > >> > My +1 >> > >> > Regards >> > JB >> > >> >> Le 28 janv. 2021 à 11:34, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> a écrit : >> >> >> >> Hi All >> >> >> >> Just to introduce myself a little, I am one of the contributors to >> Apache >> >> TomEE, and we have been embedding ActiveMQ 5 for some time, and have >> found >> >> it a really nice solution, in particular enabling users to work with >> JMS >> >> with almost no setup. >> >> >> >> We do have a desire to slim down our dependencies, and I would like to >> >> propose that ActiveMQ potentially use JSON-B as opposed to being >> tightly >> >> coupled to one specific JSON parsing library. >> >> >> >> This has previously been discussed on >> >> https://issues.apache.org/jira/projects/AMQ/issues/AMQ-7072, and it >> sounded >> >> like the community was open to using JSON-B, but would strongly want to >> >> stick with Jackson as the default serializer. >> >> >> >> I'd like to have a go at working on this. If I was able to make the >> change >> >> to use JSON-B, (and I appreciate that may need work here (which I'm >> also ok >> >> to contribute to): >> >> https://github.com/FasterXML/jackson-future-ideas/issues/19. If I >> could do >> >> this, and keep Jackson as the default serializer, would this be a >> >> contribution that the community could consider? >> >> >> >> Many thanks >> >> >> >> Jon >> > >> >>
Re: [VOTE] Terminology to replace master/slave in ActiveMQ
Yup, it's already what we discussed together for ActiveMQ (5.x): active/passive is the most accurate to me. +1 Thanks for helping there ! Regards JB On Mon, May 9, 2022 at 6:40 PM Étienne Hossack wrote: > > Given I'm still hoping to drive the PRs for AMQ-8317, and AMQ-7514 through I > apologize for not chiming in earlier due to busyness. > > But echoing the consensus as well for posterity: > > Nouns: Primary/Backup > > Adjectives: Active/Passive > > Such that for AMQ5 we'd be starting generally to use the replacement for M/S > as Active Passive. > > -- > Étienne > he/him/his > > On Sat, 7 May 2022, at 10:13 PM, Jean-Baptiste Onofré wrote: > > The purpose is not really a formal vote (as for a release for instance). > > It's more to get consensus. > > > > I think we have a consensus. > > > > +1 to proceed now :) > > > > Regards > > JB > > > > Le dim. 8 mai 2022 à 05:14, Tetreault, Lucas > > a écrit : > > > >> Here is the summary of all the votes: > >> [+1,1,-1,-1000,-1,-1] Leader/Follower > >> [-1,+1,+1,+1,+1,+1,-1,+1,+1] Primary/Backup > >> [+1, +1, +1,+1] Active/Passive > >> [+1] Active/Standby > >> [+1] capitalist/worker > >> > >> It seems like we have consensus on Primary/Backup and Active/Passive as > >> per Justin's suggestion: > >> Nouns: Primary/Backup > >> Adjectives: Active/Passive > >> > >> Does this need a formal vote since I didn't get the format right or is > >> this enough consensus that we can move forward with these terms? > >> > >> Thanks, > >> Lucas > >> > >> On 2022-05-06, 9:20 PM, "Michael André Pearce" < > >> michael.andre.pea...@me.com.INVALID> wrote: > >> > >> CAUTION: This email originated from outside of the organization. Do > >> not click links or open attachments unless you can confirm the sender and > >> know the content is safe. > >> > >> > >> > >> My understanding was previous discuss thread was that we leant for for > >> Primary/Backup > >> > >> What I was suggesting as it seemed it wasn’t closed out and it > >> continues to rumble on was a binary vote per Apache voting on that as the > >> proposal to end and close it out formally. > >> > >> As this is multiple choice this is not a vote thread, for it to be a > >> vote it needs to be a proposal with a vote of +1/0/-1 on the proposal, not > >> multi choice. Afaik. > >> > >> For the record I stand with the consensus from the previous discussion > >> as no new arguments are made here. > >> > >> As such I would in poll > >> > >> > >> [+1] primary/backup > >> [-1] Leader/Follower > >> > >> > >> > >> > >> Sent from my iPad > >> > >> > On 6 May 2022, at 07:26, Tetreault, Lucas > >> wrote: > >> > > >> > Hey folks, > >> > > >> > I don’t know if I’m actually allowed to call for a vote given I’m > >> not a committer/PMC member but Michael André Pearce made it clear on Slack > >> that this was the only way to move this discussion forward and come to a > >> final conclusion on the issue so here goes nothing. If I’m not supposed to > >> call for a vote, perhaps someone could “sponsor” this request :) > >> > > >> > > >> > A tweet [1] from a few days ago raised the issue of non-inclusive > >> terminology in the AWS docs related to ActiveMQ [2] and suggested that we > >> should replace “masterslave” with a more inclusive name for the network > >> connector transport. Replacing master/slave nomenclature in ActiveMQ was > >> raised as a Jira issue in July 2020 [3] and again on the mailing list in > >> November 2020 [7]. There was some initial work to rename the git branch > >> from master to main, some attempts at making some changes to the code ( > >> https://github.com/apache/activemq/pull/679, > >> https://github.com/apache/activemq/pull/714, > >> https://github.com/apache/activemq/pull/788) and Matt Pavlovich drafted a > >> thorough proposal on the mailing list [6], however we have not been able to > >> come to an agreement on nomenclature so these efforts seem to have stalled > >> out. > >> > > >> > > >> > > >> > If we are able to come to an agreement on nomenclature, we can move > >> forward with removing more non-inclusive terminology on the website (I will > >> follow up with some PRs to the website), in discussions with the community > >> and of course in the codebase. This will remove barriers to adoption and > >> make ActiveMQ a more approachable and inclusive project for everyone! Other > >> Apache projects such as Solr and Kafka have moved from master/slave to > >> leader/follower. Leader/follower is also recommended by the IETF [4] and > >> inclusivenaming.org [5] which is supported by companies such as Cisco, > >> Intel, and RedHat. At AWS, we have used active/standby to describe HA > >> deployments, however from previous discussions it's clear that > >> active/standby is not a viable option for this community since 'active' can > >> be used to describe so many things. If we can agree on leader/follower or > >> some alternate we would
