Apache
/
activemq-artemis
mirror of https://github.com/apache/activemq-artemis.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

NO-JIRA clarify references to ActiveMQ Classic

This commit is contained in:
Justin Bertram 2024-10-24 10:49:05 -05:00
parent 24fb38c86f
commit 24202fc30c
No known key found for this signature in database
GPG Key ID: F41830B875BB8633
17 changed files with 40 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/Stomp.java
View File

@ -101,7 +101,7 @@ public interface Stomp {
// Extensions
// ActiveMQ 5.x Scheduled Message Compatibility.
// ActiveMQ Classic Scheduled Message Compatibility.
String AMQ_SCHEDULED_DELAY = "AMQ_SCHEDULED_DELAY";
// Provides a hard time of delivery option (Epoch based)
@ -155,12 +155,12 @@ public interface Stomp {
String DURABLE_SUBSCRIPTION_NAME = "durable-subscription-name";
/**
* Backwards compatibility for STOMP clients that were using 5.x
* Backwards compatibility for STOMP clients that were using Classic
*/
String ACTIVEMQ_DURABLE_SUBSCRIPTION_NAME = "activemq.subscriptionName";
/**
* Backwards compatibility for STOMP clients that were using 5.x
* Backwards compatibility for STOMP clients that were using Classic
*/
String ACTIVEMQ_PREFETCH_SIZE = "activemq.prefetchSize";
@ -171,7 +171,7 @@ public interface Stomp {
String NO_LOCAL = "no-local";
/**
* Backwards compatibility for STOMP clients that were using 5.x
* Backwards compatibility for STOMP clients that were using Classic
*/
String ACTIVEMQ_NO_LOCAL = "activemq.noLocal";
@ -197,7 +197,7 @@ public interface Stomp {
String DURABLE_SUBSCRIPTION_NAME = "durable-subscription-name";
/**
* Backwards compatibility for STOMP clients that were using 5.x
* Backwards compatibility for STOMP clients that were using Classic
*/
String ACTIVEMQ_DURABLE_SUBSCRIPTION_NAME = "activemq.subscriptionName";
}

4
docs/migration-guide/_key-differences.adoc
View File

@ -1,4 +1,4 @@
= Differences From ActiveMQ "Classic"
= Differences From ActiveMQ Classic
== Architectural differences
@ -37,7 +37,7 @@ Once the memory is freed, messages are moved from these page files into the jour
With paging working like this, messages are read from the file journal only when the broker starts up, in order to recreate this in-memory version of the journal.
In this case, the journal is only read sequentially, meaning that there's no need to keep an index of messages in the journal.
This is one of the main differences between ActiveMQ "Classic" and Artemis.
This is one of the main differences between ActiveMQ Classic and Artemis.
It's important to understand it early on as it affects a lot of destination policy settings and how we configure brokers in order to support these scenarios properly.
== Addressing differences

4
docs/migration-guide/_message-store.adoc
View File

@ -1,11 +1,11 @@
= Message Store Migration
== ActiveMQ "Classic" KahaDB or mKahaDB
== ActiveMQ Classic KahaDB or mKahaDB
ActiveMQ Artemis supports an XML format for message store exchange.
An existing store may be exported from a broker using the command line tools and subsequently imported to another broker.
The https://github.com/apache/activemq-cli-tools[Apache ActiveMQ Command Line Tools] project provides an command line export tool for ActiveMQ "Classic" that will export a KahaDB (or mKahaDB) message store into the ActiveMQ Artemis XML format, for subsequent import by ActiveMQ Artemis.
The https://github.com/apache/activemq-cli-tools[Apache ActiveMQ Command Line Tools] project provides an command line export tool for ActiveMQ Classic that will export a KahaDB (or mKahaDB) message store into the ActiveMQ Artemis XML format, for subsequent import by ActiveMQ Artemis.
The export tool supports selective export using filters, useful if only some of your data needs to be migrated.
From version 0.2.0, the export tool has support for virtual topic consumer queue mapping, which will allow existing Openwire virtual topic consumers to resume on an ActiveMQ Artemis broker with no message loss.

2
docs/migration-guide/_preface.adoc
View File

@ -6,7 +6,7 @@ The goal of this guide is to explain these differences and help make a transitio
Migration is a fairly broad term in systems like these, so what are we talking about here?
This guide will be focused only on broker server migration.
We'll assume that the current system is a working ActiveMQ "Classic" broker with OpenWire JMS clients.
We'll assume that the current system is a working ActiveMQ Classic broker with OpenWire JMS clients.
We'll see how we can replace the broker with Artemis and leave the clients intact.
This guide is aimed at experienced ActiveMQ users that want to learn more about what's different in Artemis.

8
docs/migration-guide/_virtual-topics.adoc
View File

@ -1,6 +1,6 @@
= Virtual Topics
Virtual Topics (a specialisation of virtual destinations) in ActiveMQ "Classic" typically address two different but related problems.
Virtual Topics (a specialisation of virtual destinations) in ActiveMQ Classic typically address two different but related problems.
Let's take each in turn:
== Shared access to a JMS durable topic subscription
@ -21,7 +21,7 @@ JMS 2.0 adds the possibility of shared subscriptions with new API's that are ful
Secondly, Artemis uses a queue per topic subscriber model internally, and it is possibly to directly address the subscription queue using its Fully Qualified Queue name (FQQN).
For example, a default 5.x consumer destination for topic `VirtualTopic.Orders` subscription `A`:
For example, a default Classic consumer destination for topic `VirtualTopic.Orders` subscription `A`:
----
...
@ -42,7 +42,7 @@ If OpenWire clients cannot be modified, Artemis supports a virtual topic wildcar
The format is a comma separated list of strings pairs, delimited with a ';'.
Each pair identifies a filter to match the virtual topic consumer destination, and an int that specifies the number of path matches that terminate the consumer queue identity.
E.g: For the default 5.x virtual topic consumer prefix of `Consumer.*.` the parameter `virtualTopicConsumerWildcards` should be: `Consumer.*.>;2`.
E.g: For the default Classic virtual topic consumer prefix of `Consumer.*.` the parameter `virtualTopicConsumerWildcards` should be: `Consumer.*.>;2`.
However, there is a caveat because this value needs to be encoded in a uri for the xml configuration.
Any unsafe url characters , in this case: `> ;` need to be escaped with their hex code point representation;
leading to a value of `Consumer.*.%3E%3B2`.
@ -50,7 +50,7 @@ In this way a consumer destination of `Consumer.A.VirtualTopic.Orders` will be t
== Durable topic subscribers in a network of brokers
The store and forward network bridges in 5.x create a durable subscriber per destination.
The store and forward network bridges in Classic create a durable subscriber per destination.
As demand migrates across a network, duplicate durable subs get created on each node in the network, but they do not migrate.
The end result can result in duplicate message storage and ultimately duplicate delivery, which is not good.
When durable subscribers map to virtual topic subscriber queues, the queues can migrate, and the problem can be avoided.

2
docs/migration-guide/index.adoc
View File

@ -1,6 +1,6 @@
= Apache ActiveMQ Artemis Migration Guide
The migration guide outlines how users can migrate an existing ActiveMQ "Classic" broker installation to ActiveMQ Artemis.
The migration guide outlines how users can migrate an existing ActiveMQ Classic broker installation to ActiveMQ Artemis.
include::_preface.adoc[leveloffset=1]
include::_key-differences.adoc[leveloffset=1]

2
docs/user-manual/examples.adoc
View File

@ -470,7 +470,7 @@ When non-transacted sessions are used, once and only once message delivery is no
The `Openwire` example shows how to configure an Apache ActiveMQ Artemis server to communicate with an Apache ActiveMQ Artemis JMS client that uses open-wire protocol.
You will find the queue example for open wire, and the chat example.
The virtual-topic-mapping examples shows how to map the ActiveMQ "Classic" Virtual Topic naming convention to work with the Artemis Address model.
The virtual-topic-mapping examples shows how to map the ActiveMQ Classic Virtual Topic naming convention to work with the Artemis Address model.
== Paging

2
docs/user-manual/openwire.adoc
View File

@ -2,7 +2,7 @@
:idprefix:
:idseparator: -
Apache ActiveMQ Artemis supports the http://activemq.apache.org/openwire.html[OpenWire] protocol so that an Apache ActiveMQ "Classic" JMS client can talk directly to an Apache ActiveMQ Artemis server.
Apache ActiveMQ Artemis supports the http://activemq.apache.org/openwire.html[OpenWire] protocol so that an Apache ActiveMQ Classic JMS client can talk directly to an Apache ActiveMQ Artemis server.
By default there is an `acceptor` configured to accept OpenWire connections on port `61616`.
See the general xref:protocols-interoperability.adoc#protocols-and-interoperability[Protocols and Interoperability] chapter for details on configuring an `acceptor` for OpenWire.

6
docs/user-manual/protocols-interoperability.adoc
View File

@ -46,7 +46,7 @@ Please see xref:stomp.adoc#stomp[Stomp] for more details.
=== OpenWire
ActiveMQ Classic defines its own wire protocol: OpenWire.
In order to support ActiveMQ "Classic" clients, Apache ActiveMQ Artemis supports OpenWire.
In order to support ActiveMQ Classic clients, Apache ActiveMQ Artemis supports OpenWire.
Any ActiveMQ 5.12.x or higher can be used with Apache ActiveMQ Artemis.
Please see xref:openwire.adoc#openwire[OpenWire] for more details.
@ -54,7 +54,7 @@ Please see xref:openwire.adoc#openwire[OpenWire] for more details.
=== Core
ActiveMQ Classic defines its own wire protocol: OpenWire.
In order to support ActiveMQ "Classic" clients, Apache ActiveMQ Artemis supports OpenWire.
In order to support ActiveMQ Classic clients, Apache ActiveMQ Artemis supports OpenWire.
Any ActiveMQ 5.12.x or higher can be used with Apache ActiveMQ Artemis.
Please see xref:core.adoc#using-core[Core] for more details.
@ -107,7 +107,7 @@ Here are the supported protocols and their corresponding value used in the `prot
| Protocol | `protocols` value
| Core (Artemis & HornetQ native) | `CORE`
| OpenWire (5.x native) | `OPENWIRE`
| OpenWire (Classic native) | `OPENWIRE`
| AMQP | `AMQP`
| MQTT | `MQTT`
| STOMP | `STOMP`

14
docs/user-manual/security.adoc
View File

@ -225,8 +225,8 @@ See the JavaDoc on `org.apache.activemq.artemis.core.server.SecuritySettingPlugi
==== LegacyLDAPSecuritySettingPlugin
This plugin will read the security information that was previously handled by http://activemq.apache.org/security.html[`LDAPAuthorizationMap`] and the http://activemq.apache.org/cached-ldap-authorization-module.html[`cachedLDAPAuthorizationMap`] in Apache ActiveMQ "Classic" and turn it into Artemis security settings where possible.
The security implementations of ActiveMQ "Classic" and Artemis don't match perfectly so some translation must occur to achieve near equivalent functionality.
This plugin will read the security information that was previously handled by http://activemq.apache.org/security.html[`LDAPAuthorizationMap`] and the http://activemq.apache.org/cached-ldap-authorization-module.html[`cachedLDAPAuthorizationMap`] in Apache ActiveMQ Classic and turn it into Artemis security settings where possible.
The security implementations of ActiveMQ Classic and Artemis don't match perfectly so some translation must occur to achieve near equivalent functionality.
Here is an example of the plugin's configuration:
@ -323,12 +323,12 @@ The default value is `false`.
allowQueueAdminOnRead::
Whether or not to map the legacy `read` permission to the `createDurableQueue`, `createNonDurableQueue`, and `deleteDurableQueue` permissions so that JMS clients can create durable and non-durable subscriptions without needing the `admin` permission.
This was allowed in ActiveMQ "Classic".
This was allowed in ActiveMQ Classic.
The default value is `false`.
The name of the queue or topic defined in LDAP will serve as the "match" for the security-setting, the permission value will be mapped from the ActiveMQ "Classic" type to the Artemis type, and the role will be mapped as-is.
The name of the queue or topic defined in LDAP will serve as the "match" for the security-setting, the permission value will be mapped from the ActiveMQ Classic type to the Artemis type, and the role will be mapped as-is.
ActiveMQ "Classic" only has 3 permission types - `read`, `write`, and `admin`.
ActiveMQ Classic only has 3 permission types - `read`, `write`, and `admin`.
These permission types are described on their http://activemq.apache.org/security.html[website].
However, as described previously, ActiveMQ Artemis has 9 permission types - `createAddress`, `deleteAddress`, `createDurableQueue`, `deleteDurableQueue`, `createNonDurableQueue`, `deleteNonDurableQueue`, `send`, `consume`, `browse`, and `manage`.
Here's how the old types are mapped to the new types:
@ -344,9 +344,9 @@ admin::
As mentioned, there are a few places where a translation was performed to achieve some equivalence.:
* This mapping doesn't include the Artemis `manage` permission type by default since there is no type analogous for that in ActiveMQ "Classic".
* This mapping doesn't include the Artemis `manage` permission type by default since there is no type analogous for that in ActiveMQ Classic.
However, if `mapAdminToManage` is `true` then the legacy `admin` permission will be mapped to the `manage` permission.
* The `admin` permission in ActiveMQ "Classic" relates to whether or not the broker will auto-create a destination if it doesn't exist and the user sends a message to it.
* The `admin` permission in ActiveMQ Classic relates to whether or not the broker will auto-create a destination if it doesn't exist and the user sends a message to it.
Artemis automatically allows the automatic creation of a destination if the user has permission to send message to it.
Therefore, the plugin will map the `admin` permission to the 6 aforementioned permissions in Artemis by default.
If `mapAdminToManage` is `true` then the legacy `admin` permission will be mapped to the `manage` permission as well.

2
docs/user-manual/stomp.adoc
View File

@ -283,7 +283,7 @@ The `stomp-websockets` xref:examples.adoc[example] shows how to configure an Apa
STOMP clients can use the `consumer-window-size` header on the `SUBSCRIBE` frame to control the flow of messages to clients.
This is broadly discussed in the xref:flow-control.adoc#flow-control[Flow Control] chapter.
This ability is similar to the `activemq.prefetchSize` header supported by ActiveMQ "Classic".
This ability is similar to the `activemq.prefetchSize` header supported by ActiveMQ Classic.
However, that header specifies the size in terms of _messages_ whereas `consumer-window-size` specifies the size in terms of _bytes_.
ActiveMQ Artemis supports the `activemq.prefetchSize` header for backwards compatibility but the value will be interpreted as _bytes_ just like `consumer-window-size` would be.
If both `activemq.prefetchSize` and `consumer-window-size` are set then the value for `consumer-window-size` will be used.

2
docs/user-manual/tomcat.adoc
View File

@ -6,7 +6,7 @@
Apache ActiveMQ Artemis provides support for configuring the client in the `context.xml` of the Tomcat container.
This is very similar to the way this is done in ActiveMQ "Classic" so anyone migrating should find this familiar.
This is very similar to the way this is done in ActiveMQ Classic so anyone migrating should find this familiar.
Please note though the connection url and properties that can be set for ActiveMQ Artemis are different please see https://activemq.apache.org/artemis/migration/[Migration Documentation]
=== Example of Connection Factory

2
docs/user-manual/upgrading.adoc
View File

@ -2,7 +2,7 @@
:idprefix:
:idseparator: -
Apache ActiveMQ "Classic" (and previous versions) is runnable out of the box by executing the command: `./bin/activemq run`.
Apache ActiveMQ Classic (and previous versions) is runnable out of the box by executing the command: `./bin/activemq run`.
The ActiveMQ Artemis broker follows a different paradigm where the project distribution serves as the broker "home" and one or more broker "instances" are created which reference the "home" for resources (e.g. jar files) which can be safely shared between broker instances.
Therefore, an instance of the broker must be created before it can be run.
This may seems like an overhead at first glance, but it becomes very practical when updating to a new Artemis version for example.

14
docs/user-manual/versions.adoc
View File

@ -539,7 +539,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
* xref:ha.adoc#apache-zookeeper-integration[Replication integrated with ZooKeeper]
* xref:connection-routers.adoc#connection-routers[Connection Routers]
* xref:core-bridges.adoc#configuring-core-bridges[Concurrency] configuration for core bridges.
* xref:filter-expressions.adoc#xpath[XPath filter expressions] (for parity with ActiveMQ "Classic").
* xref:filter-expressions.adoc#xpath[XPath filter expressions] (for parity with ActiveMQ Classic).
=== Upgrading from 2.17.0
@ -593,7 +593,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
=== Highlights
* xref:broker-plugins.adoc#using-the-brokermessageauthorizationplugin[Message-level authorization] similar to ActiveMQ "Classic".
* xref:broker-plugins.adoc#using-the-brokermessageauthorizationplugin[Message-level authorization] similar to ActiveMQ Classic.
* A count of addresses and queues is now available from the management API.
* You can now reload the broker's configuration from disk via the management API rather than waiting for the periodic disk scan to pick it up
* Performance improvements on libaio journal.
@ -913,7 +913,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
=== Highlights
* Support advanced destination options like `consumersBeforeDispatchStarts` and `timeBeforeDispatchStarts` from 5.x.
* Support advanced destination options like `consumersBeforeDispatchStarts` and `timeBeforeDispatchStarts` from Classic.
* Add support for delays before deleting addresses and queues via xref:address-settings.adoc#address-settings[`auto-delete-queues-delay` and `auto-delete-addresses-delay` Address Settings].
* Support xref:web-server.adoc#embedded-web-server[logging HTTP access].
* Add a CLI command to purge a queue.
@ -926,7 +926,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
* Support xref:security.adoc#ldaploginmodule[connection pooling in LDAPLoginModule].
* Support configuring a default consumer window size via xref:address-settings.adoc#address-settings[`default-consumer-window-size` Address Setting].
* Support xref:masking-passwords.adoc#masking-passwords[masking] `key-store-password` and `trust-store-password` in management.xml.
* Support xref:message-grouping.adoc#closing-a-message-group[`JMSXGroupSeq` -1 to close/reset message groups] from 5.x.
* Support xref:message-grouping.adoc#closing-a-message-group[`JMSXGroupSeq` -1 to close/reset message groups] from Classic.
* Allow configuration of xref:management.adoc#remote-jmx-access[RMI registry port].
* Support routing-type configuration on xref:core-bridges.adoc#configuring-core-bridges[core bridge].
* Move artemis-native as its own project, as https://github.com/apache/activemq-artemis-native[activemq-artemis-native].
@ -984,7 +984,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
=== Highlights
* xref:exclusive-queues.adoc#exclusive-queues[Exclusive consumers].
* Equivalent ActiveMQ "Classic" Virtual Topic naming abilities.
* Equivalent ActiveMQ Classic Virtual Topic naming abilities.
* SSL Certificate revocation list.
* xref:last-value-queues.adoc#last-value-queues[Last-value queue] support for OpenWire.
* Support xref:masking-passwords.adoc#masking-passwords[masked passwords] in bootstrap.xm and login.config
@ -1209,7 +1209,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
* Improvements around performance
* OSGi support.
* Support functionality equivalent to all 5.x JAAS login modules including:
* Support functionality equivalent to all Classic JAAS login modules including:
** Properties file
** LDAP
** SSL certificate
@ -1238,7 +1238,7 @@ https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&versio
=== Highlights
* First release of the https://lists.apache.org/thread/7y4o61zzk5y9bdjqsho2p6k7860kmzbt[donated code-base] as ActiveMQ Artemis!
* Lots of features for parity with ActiveMQ "Classic" including:
* Lots of features for parity with ActiveMQ Classic including:
** OpenWire support
** AMQP 1.0 support
** URL based connections

2
tests/activemq5-unit-tests/pom.xml
View File

@ -25,7 +25,7 @@
<artifactId>activemq5-unit-tests</artifactId>
<packaging>jar</packaging>
<name>ActiveMQ5.x unit tests</name>
<name>ActiveMQ Classic unit tests</name>
<properties>
<activemq.basedir>${project.basedir}/../..</activemq.basedir>

2
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt/MQTTTest.java
View File

@ -1164,7 +1164,7 @@ public class MQTTTest extends MQTTTestSupport {
@Disabled
@Test
@Timeout(90)
// TODO ActiveMQ 5.x does not reset the message id generator even after a clean session. In Artemis we always reset.
// TODO ActiveMQ Classic does not reset the message id generator even after a clean session. In Artemis we always reset.
// If there is a good reason for this we should follow ActiveMQ.
public void testPacketIdGeneratorCleanSession() throws Exception {
final String[] cleanClientIds = new String[]{"", "clean-packetid", null};

2
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/openwire/SimpleOpenWireTest.java
View File

@ -1718,7 +1718,7 @@ public class SimpleOpenWireTest extends BasicOpenWireTest {
XidImpl xid1 = new XidImpl(xid);
Transaction transaction = server.getResourceManager().getTransaction(xid1);
//amq5.x doesn't pass suspend flags to broker,
//ActiveMQ Classic doesn't pass suspend flags to broker,
//directly suspend the tx
transaction.suspend();