Durable changes made via the management API (e.g. adding
security-settings, adding address-settings, adding diverts) can be
reverted when reloading the XML at runtime.
Currently dead-letter and expiry addresses can only be identified on the
web console if they perfectly match a configurable string value (i.e.
"DLQ" and "ExpiryQueue" by default respectively). However, lots of users
have multiple dead-letter and expiry addresses which follow the same
naming pattern. The web console should support using a regular
expression so all of these addresses can be properly identified.
This is a follow-up from ARTEMIS-2322.
The changes related to expired message are only there because
QueueFilterPredicate had a bug where the rate was correlated to expired
messages. When I fixed that I noticed that expired messages was actually
missing so I added it.
Casting the result of getPeerCertificates() to X509Certificate[] mirrors
what is done in the ActiveMQ "Classic" code-base.
A few tests which were imported from ActiveMQ "Classic" to verify our
OpenWire implementation were removed as they relied on a "stub"
implementation of javax.net.ssl.SSLSession that never would have worked
across multiple JDKs once javax.security.cert.X509Certificate[] was
removed. Furthermore, the tests appeared to be related to the OpenWire
*client* and not relevant to our broker-side implementation.
I decided on NO-JIRA as this is only support tests themselves. No need for release notes on this commit:
I changed logging-CI.properties to be the same as logging.properties, with the only exception as file and console are limited by WARN.
while the AssertionLogger would still get INFO. as that's required for certain tests.
Aside from adding audit logging for message acknowledgement this commit
also consolidates the two nearly identical acknowledge method
implementations in o.a.a.a.c.s.i.QueueImpl. This avoids duplicating
code for audit logging, plugin invocation, etc. There is no semantic
change.
Due to the multi-threaded AMQP implementation the ThreadLocal variables
used by the AuditLogger to track the username and remote address don't
work properly. Changes include:
- Passing the audit Subject (set during authentication) and the remote
address explicitly for audit logging on the relevant ServerSession
methods rather than relying on the AuditLogger's ThreadLocal
variables
- Audit logging core session creation *after* successful authentication
so that we have the proper Subject; this is especially important for
the SSL certificate authentication use-case
- Renaming some methods and variables in AuditLogger to more accurately
reflect their intended use
- Adding JavaDoc and refactoring the getCaller methods on AuditLogger
- Refactor audit log testing and add a new test
Clebert Suconic
Domenico Francesco Bruscino
Justin Bertram
Andy Taylor
Robbie Gemmell
franz1981
Howard Gao