Mainly refactoring the address docs. This commit has the following
changes:
- Remove examples for discouraged use-cases (e.g. using anycast and
multicast on the same address).
- Reword to use configuration terms wherever possible. For example,
instead of saying "point-to-point" (which is not a configuration term)
say "anycast". References to things like "point-to-point" and
"publish-subscribe" are still there since users are familiar with these
terms. They're just used much less often.
- Remove duplicate explanation of exclusive queues.
- Remove duplicate explanation of auto-create and auto-delete elements.
- Re-create graphics and include the master SVGs for potential updates
later.
- Give non-destructive queues its own chapter.
- Add details about specifying routing type using a message property.
- Update the styling on the user manual's cover page to look better.
- Lots of re-wording for clarity's sake.
- Re-order sub-sections for clarity's sake.
- Break up the address model and the settings documentation. The
settings documentation is large and deserves its own chapter. The
original anchor link is still available with a link to the new chapter.
In general the address-specific documentation should be much more clear,
concise, and consistent now.
JGroups 3.x hasn't been updated in some time now. The last release was
in April 2020 almost 2 years ago. Lots of protocols have been updated
and added and users are wanting to use them. There is also increasing
concern about using older components triggered mainly by other
recently-discovered high-profile vulnerabilities in the wider Open
Source Java community.
This commit bumps JGroups up to the latest release - 5.2.0.Final.
However, there is a cost associated with upgrading.
The old-style properties configuration is no longer supported. I think
it's unlikely that end-users are leveraging this because it is not
exposed via broker.xml. The JGroups XML configuration has been around
for a long time, is widely adopted, and is still supported. I expect
most (if not all) users are using this. However, a handful of tests
needed to be updated and/or removed to deal with this absence.
Some protocols and/or protocol properties are no longer supported. This
means that users may have to change their JGroups stack configurations
when they upgrade. For example, our own clustered-jgroups example had to
be updated or it wouldn't run properly.
MQTT 5 is an OASIS standard which debuted in March 2019. It boasts
numerous improvments over its predecessor (i.e. MQTT 3.1.1) which will
benefit users. These improvements are summarized in the specification
at:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901293
The specification describes all the behavior necessary for a client or
server to conform. The spec is highlighted with special "normative"
conformance statements which distill the descriptions into concise
terms. The specification provides a helpful summary of all these
statements. See:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901292
This commit implements all of the mandatory elements from the
specification and provides tests which are identified using the
corresponding normative conformance statement. All normative
conformance statements either have an explicit test or are noted in
comments with an explanation of why an explicit test doesn't exist. See
org.apache.activemq.artemis.tests.integration.mqtt5 for all those
details.
This commit also includes documentation about how to configure
everything related to the new MQTT 5 features.
* Add BindingDTO to allow configuring multiple addresses to listen on
* Start a new ServerConnector for each binding and deploy the corresponding web-applications
* Update documentation and tests
* Add tests to verify old and new configuration style produce equal results
* Add BindingDTO to allow configuring multiple addresses to listen on
* Start a new ServerConnector for each binding and deploy the corresponding web-applications
* Update documentation and tests
* Add tests to verify old and new configuration style produce equal results
scenario - avoid paging, if address is full chain another broker and produce to the head, consume from the tail using producer and consumer roles to partition connections. When tail is drained, drop it.
- adds a option to treat an idle consumer as slow
- adds basic support for credit based address blocking ARTEMIS-2097
- adds some more visiblity to address memory usage and balancer attribute modifier operations
Adds support for extra configuration options to LDAP login module to
prepare for supporting any future/custom string configuration in LDAP
directory context creation.
Details:
- Changed LDAPLoginModule to pass any string configuration not
recognized by the module itself to the InitialDirContext contruction
environment.
- Changed the static LDAPLoginModule configuration key fields to an
enum to be able to loop through the specified keys (e.g. to filter out
the internal LDAPLoginModule configuration keys from the keys passed to
InitialDirContext).
- Few fixes for issues reported by static analysis tools.
- Tested that LDAP authentication with TLS+GSSAPI works against a
recent Windows AD server with Java
OpenJDK11U-jdk_x64_windows_hotspot_11.0.13_8 by setting the property
com.sun.jndi.ldap.tls.cbtype (see ARTEMIS-3140) in JAAS login.conf.
- Moved LDAPLoginModuleTest to the correct package to be able to
access LDAPLoginModule package privates from the test code.
- Added a test to LDAPLoginModuleTest for the task changes.
- Updated documentation to reflect the changes.
Back in version 2.17.0 we began to provide Maven artifacts for Jakarta
Messaging client resources. This commit expands that support in the
following ways:
- Distribute a Jakarta Messaging 3.0 client with the broker (in the
'lib/client' directory alongside the JMS client.
- Update documentation.
- Add example using the Jakarta Messaging client.
- Update Artemis CLI to use core instead of JMS as it was causing
conflicts with the new Jarkarta Messaging client.
- Add example to build Jarkarta Messaging version of the JCA RA for
deployment into Jakarta EE 9 application servers.
The provider of an SSL key/trust store is different from that store's
type. However, the broker currently doesn't differentiate these and uses
the provider for both. Changing this *may* potentially break existing
users who are setting the provider, but I don't see any way to avoid
that. This is a bug that needs to be fixed in order to support use-cases
like PKCS#11.
Change summary:
- Added documentation.
- Consolidated several 2-way SSL tests classes into a single
parameterized test class. All these classes were essentially the same
except for a few key test parameters. Consolidating them avoided
having to update the same code in multiple places.
- Expanded tests to include different providers & types.
- Regenerated all SSL artifacts to allow tests to pass with new
constraints.
- Improved logging for when SSL handler initialization fails.
Change summary:
- Remove the existing Xalan-based XPath evaluator since Xalan appears
to be no longer maintained.
- Implement a JAXP XPath evaluator (from the ActiveMQ 5.x code-base).
- Pull in the changes from https://issues.apache.org/jira/browse/AMQ-5333
to enable configurable XML parser features.
- Add a method to the base Message interface to make it easier to get
the message body as a string. This relieves the filter from having
to deal with message implementation details.
- Update the Qpid JMS client to get the jms.validateSelector parameter.
Justin Bertram
AntonRoskvist
Matteo Baccan
Domenico Francesco Bruscino
Luis De Bello
Gergő Rubint
Paul Wright
Clebert Suconic
Marlon Müller
gtully
pahamala
Erwin Dondorp
Erwin Dondorp
Robbie Gemmell
Andy Taylor
franz1981
tdinev
Erwin Dondorp
Martyn Taylor
sebthom
Jan Šmucr
Ryan Yeats