177e6820b541e0a71b952eebf503a4d2235910c5
e34fd09ce325a551bf2eaf579854e2e107435502
e065d25b6fb4cdfa7f5b72afd52d6f4771b50634
af9bd7b84aad32e4fe30f2c8909e51cf7300b475
f4bdacbc4cb46b308f80391940890c74bf111ecd
74951d9221b29336c6575de9390a8557114e10eb
fe0ca4d84fc587b701e4b83ae8e5f2240c222842
b08b91a32faa89cdff4403b532e60d96084f2d4a
85857ab8eb1b1eca2498306239740e0e39d2acd4
e02ec69021f24220c0b91b8324382c9630415276
bf9f6d213bf6b3bf4fd7e15430ada8c9954e69ce
2d806807b8d9006cf642392ad5da9878394cebae
52a4157bbb898ee8fd8d7f13fffca71a9c368630
53bb3ea1833cddda6c2ded70d3149286c8207570
d5f152c7254c378707b12ad4a0b798fdb8cb7b10
b3529dcea428fa697aacbceacc6641e47cfb74ba
246bf083914c7acbb05a7fe0904c471331242c39
8a04ee07de8a7c863daf37a07a1176131151caa0
6cb68f2ce923ea3c2400c21967b2003175c8a0f4
9873fccf744c0cb0a25dd905fab67ea52ef7aa7d
See PR for individual commits which were squashed to form this change. This closes#5320
The broker uses unique IDs for logging statements. As logging changes
over time we need a way to "retire" these IDs (e.g. when certain
logging statements are no longer needed) to ensure they are not used
This commit does the following:
- Removes all the logging methods which are no longer used and
"retires" the corresponding ID (i.e. adds them to the `retiredIDs`
list for that LogBundle).
- Updates the validation for IDs that have been retired or are in
active use including a new suggestion about a valid ID to use when an
invalid ID is found.
- Fixes all the regular expressions in all the various uses of
`@LogBundle` to ensure there are no overlaps to prevent duplicates
between bundles.
Changes from myself and Robbie Gemmell (see PR). This closes#5303.
Updates artemis-log-annotation-processor to use artemis-project so that
artemis-pom can reference artemis-log-annotation-processor without cycle.
Split out its tests to their own module to faciltate, also exercising the
profile mechanism to enable the processor usage with trigger file.
Simplify disabling processing in the module using maven.compiler.proc prop
available since maven-compiler-plugin 3.13.0
Uses a dummy non-processor path at root to 'disable' processsing on JDK < 23,
accounting for Maven 3 not being able to unset maven.compiler.proc from a
parent, and JDKs < 21 requiring newest builds to support -proc:full value
needed otherwise to reenable processing once explicitly disabled.
This commit uses lambdas or method references wherever possible. There
are still a handful of places that appear like they could be changed but
couldn't mainly because they use "this" and the meaning of "this"
changes when using a lambda.
This commit does the following:
- deprecate all QueueConfiguration ctors
- add `of` static factory methods for all the deprecated ctors
- replace any uses of the normal ctors with the `of` counterparts
This makes the code more concise and readable.
This commit does the following:
- deprecate the verbosely named `toSimpleString` static factory
methods
- add `of` static factory methods for all the ctors
- replace any uses of the normal ctors with the `of` counterparts
This makes the code more concise and readable.
This commit does the following:
- Replaces non-inclusive terms (e.g. master, slave, etc.) in the
source, docs, & configuration.
- Supports previous configuration elements, but logs when old elements
are used.
- Provides migration documentation.
- Updates XSD with new config elements and simplifies by combining some
overlapping complexTypes.
- Removes ambiguous "live" language that's used with regard to high
availability.
- Standardizes use of "primary," "backup," "active," & "passive" as
nomenclature to describe both configuration & runtime state for high
availability.
Fixing the creation of the recovery connection factory so that
useTopologyForLoadBalancing is properly set.
Issue: https://issues.apache.org/jira/browse/ARTEMIS-4508
Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>
When big messages are produced if a consumer receives an expired message, the credits are not updated, so if the consumer is too slow and an expiry delay has been set, we can end up with a situation where there are no more credits which prevents the consumer from receiving any more messages.
* Unsetting the transation timeout on the TransactionManager after the
onMessage has been called
Issue: https://issues.apache.org/jira/browse/ARTEMIS-4427
Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>
