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.
Throughout the years, the standard mechanism for storing passwords has evolved.
In the beginning, passwords were stored in plaintext. Developers are now
encouraged to leverage adaptive one-way functions to store a password. Using a
two-way function by default for storing passwords without a warning could lead
users to a false sense of security.
We've traditionally used org.apache.activemq.artemis.utils.Base64 for
Base64 encoding/decoding. This implementation is based on public domain
code from http://iharder.net/base64.
In Java 8 java.util.Base64 was introduced. I assumed we hadn't switched
to this implementation for performance reasons so I created a simple
JMH-based test to compare the two implementations and it appears to me
that java.util.Base64 is significantly faster than our current
implementation. Using the JDK's class will simplify our code and
improve performance. Also, it should be 100% backwards compatible
since Base64 encoding/decoding is standardized.
The run command uses the artemis.profile and log4j2.properties files while all
other CLI commands use the artemis-utility.profile and log4j2-default.properties
files.
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.
Notice that I'm keeping the old argument here as hidden
As I keep using this myself, my brain always go to ./artemis queue stat --sleep
So, I think people would feel more comfortable if the parameter was renamed.
Due to https://github.com/apache/maven-apache-parent/pull/188 the
property `maven.compiler.release` is now being set which precludes
exporting and using any internal Java classes. Therefore this commit
removed references to `--add-exports` from the build, switches to
reflection, and adds `--add-opens` to the runtime JVM parameters.
Justin Bertram
Gary Tully
AntonRoskvist
Robbie Gemmell
Clebert Suconic
Domenico Francesco Bruscino
dependabot[bot]