[jira] [Work logged] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
[ https://issues.apache.org/jira/browse/ARTEMIS-4263?focusedWorklogId=859482=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859482 ] ASF GitHub Bot logged work on ARTEMIS-4263: --- Author: ASF GitHub Bot Created on: 27/Apr/23 21:13 Start Date: 27/Apr/23 21:13 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4458: URL: https://github.com/apache/activemq-artemis/pull/4458#issuecomment-1526484809 What's the use-case for this? Also, you can omit the square brackets and dash from your commit message so that it's just: ``` ARTEMIS-4263 authenticator to adapt to artemis jaas login modules callback handler ``` IMO it makes it easier to read and follows the pattern from the [hacking guide](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/code.md#commitMessageDetails). Issue Time Tracking --- Worklog Id: (was: 859482) Time Spent: 20m (was: 10m) > support access to our JaasCallbackhandler from a jdk http Authenticator > --- > > Key: ARTEMIS-4263 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4263 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > To allow the jolokia jvm agent to utilise jaas with our callback handler, it > is necessary to provide a wrapper that is aware of the capabilities of the > various artemis login modules and provide the necessary callback > implementation > Jolokia supports an externsion point in the form of a > com.sun.net.httpserver.Authenticator that we can use. > This will allow us to reduce the surface are that we expose to support > jolokia, avoiding the need for jetty. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4245) Expose web SNI settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4245?focusedWorklogId=859466=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859466
]
ASF GitHub Bot logged work on ARTEMIS-4245:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 18:29
Start Date: 27/Apr/23 18:29
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4441:
URL: https://github.com/apache/activemq-artemis/pull/4441#discussion_r1179543812
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -283,6 +298,40 @@ public void simpleSecureServer() throws Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckEnabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(true);
+ }
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckDisabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(false);
+ }
Review Comment:
We could do that instead yes.
Issue Time Tracking
---
Worklog Id: (was: 859466)
Time Spent: 50m (was: 40m)
> Expose web SNI settings
> ---
>
> Key: ARTEMIS-4245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4245
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Expose sniHostCheck and sniRequired settings in the web config.
> {code:xml}
>
>http://localhost:8161; sniHostCheck="false"
> sniRequired="false">
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4245) Expose web SNI settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4245?focusedWorklogId=859464=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859464
]
ASF GitHub Bot logged work on ARTEMIS-4245:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 18:24
Start Date: 27/Apr/23 18:24
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4441:
URL: https://github.com/apache/activemq-artemis/pull/4441#discussion_r1179539330
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -215,11 +221,11 @@ public void testComponentStopStartBehavior() throws
Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
- @Test
- public void simpleSecureServer() throws Exception {
+ private WebServerComponent startSimpleSecureServer(String keyStorePath,
String keyStorePassword, Boolean sniHostCheck) throws Exception {
BindingDTO bindingDTO = new BindingDTO();
bindingDTO.uri = "https://localhost:0;;
bindingDTO.keyStorePath = "./src/test/resources/server.keystore";
+ bindingDTO.setSniHostCheck(sniHostCheck);
Review Comment:
Sure, but the comment was just about 'getting the default behaviour' rather
than explicitly setting the null (whichone testdoes), and instead relying on
the bonafiide default behaviour so it could be verified to match what we expect.
Issue Time Tracking
---
Worklog Id: (was: 859464)
Time Spent: 40m (was: 0.5h)
> Expose web SNI settings
> ---
>
> Key: ARTEMIS-4245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4245
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Expose sniHostCheck and sniRequired settings in the web config.
> {code:xml}
>
>http://localhost:8161; sniHostCheck="false"
> sniRequired="false">
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4260) address-setting with wildcard not inherited by actual address
[
https://issues.apache.org/jira/browse/ARTEMIS-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717315#comment-17717315
]
Justin Bertram commented on ARTEMIS-4260:
-
FWIW, I created ARTEMIS-4262 for updating the documentation and sent [a
PR|https://github.com/apache/activemq-artemis/pull/4455] that's now been merged.
> address-setting with wildcard not inherited by actual address
> -
>
> Key: ARTEMIS-4260
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4260
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: arne anka
>Assignee: Justin Bertram
>Priority: Minor
>
> In my broker.xml I got
> {code:java}
>
> IMP.DLQ
> IMP.ExpiryQueue
> {code}
> {code:java}
>
>
>
>
>
>
>
> {code}
> According to what I read in docs and examples, all adresses starting with
> {noformat}
> IMP{noformat}
> should inherit the DLQ and Expiry adresses from the address-setting.
> Yet, when starting Artemis it logs
> {code:java}
> 2023-04-26 16:05:59,810 WARN [org.apache.activemq.artemis.core.server]
> AMQ222165: No Dead Letter Address configured for queue IMP_MISC in
> AddressSettings
> 2023-04-26 16:05:59,811 WARN [org.apache.activemq.artemis.core.server]
> AMQ222166: No Expiry Address configured for queue IMP_MISC in AddressSettings
> {code}
> I am currently fighting my way through the code, looking for the place where
> the actual merging happens, but no luck so far.
> Maybe in a first step, someone can give me a pointer where to look (and maybe
> how to log)?
> And is there a way to see the actual configuration of an address once Artemis
> is up and running? Didn't find anything in the Web-Console.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4262) Clarify wildcard syntax documentation
[ https://issues.apache.org/jira/browse/ARTEMIS-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4262. - Fix Version/s: 2.29.0 Resolution: Fixed > Clarify wildcard syntax documentation > - > > Key: ARTEMIS-4262 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4262 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4262) Clarify wildcard syntax documentation
[ https://issues.apache.org/jira/browse/ARTEMIS-4262?focusedWorklogId=859457=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859457 ] ASF GitHub Bot logged work on ARTEMIS-4262: --- Author: ASF GitHub Bot Created on: 27/Apr/23 17:26 Start Date: 27/Apr/23 17:26 Worklog Time Spent: 10m Work Description: brusdev merged PR #4455: URL: https://github.com/apache/activemq-artemis/pull/4455 Issue Time Tracking --- Worklog Id: (was: 859457) Remaining Estimate: 0h Time Spent: 10m > Clarify wildcard syntax documentation > - > > Key: ARTEMIS-4262 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4262 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4262) Clarify wildcard syntax documentation
[ https://issues.apache.org/jira/browse/ARTEMIS-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717311#comment-17717311 ] ASF subversion and git services commented on ARTEMIS-4262: -- Commit aad3d0b90d4e15929fc19d7aa40c1d24749eb670 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=aad3d0b90d ] ARTEMIS-4262 clarify wildcard syntax documentation > Clarify wildcard syntax documentation > - > > Key: ARTEMIS-4262 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4262 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4245) Expose web SNI settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4245?focusedWorklogId=859430=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859430
]
ASF GitHub Bot logged work on ARTEMIS-4245:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 15:54
Start Date: 27/Apr/23 15:54
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4441:
URL: https://github.com/apache/activemq-artemis/pull/4441#discussion_r1179376675
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -215,11 +221,11 @@ public void testComponentStopStartBehavior() throws
Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
- @Test
- public void simpleSecureServer() throws Exception {
+ private WebServerComponent startSimpleSecureServer(String keyStorePath,
String keyStorePassword, Boolean sniHostCheck) throws Exception {
BindingDTO bindingDTO = new BindingDTO();
bindingDTO.uri = "https://localhost:0;;
bindingDTO.keyStorePath = "./src/test/resources/server.keystore";
+ bindingDTO.setSniHostCheck(sniHostCheck);
Review Comment:
If the test doesn't set bindingDTO.sniHostCheck the WebServerComponent
behaviour depends on
org.eclipse.jetty.server.SecureRequestCustomizer._sniHostCheck default value
and it already changed from 9.x to 10.x
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -283,6 +298,40 @@ public void simpleSecureServer() throws Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckEnabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(true);
+ }
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckDisabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(false);
+ }
Review Comment:
Maybe we should enable sniHostCheck by default because
org.eclipse.jetty.server.SecureRequestCustomizer._sniHostCheck default value
already changed from 9.x to 10.x
Issue Time Tracking
---
Worklog Id: (was: 859430)
Time Spent: 0.5h (was: 20m)
> Expose web SNI settings
> ---
>
> Key: ARTEMIS-4245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4245
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Expose sniHostCheck and sniRequired settings in the web config.
> {code:xml}
>
>http://localhost:8161; sniHostCheck="false"
> sniRequired="false">
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
[ https://issues.apache.org/jira/browse/ARTEMIS-4263?focusedWorklogId=859428=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859428 ] ASF GitHub Bot logged work on ARTEMIS-4263: --- Author: ASF GitHub Bot Created on: 27/Apr/23 15:37 Start Date: 27/Apr/23 15:37 Worklog Time Spent: 10m Work Description: gtully opened a new pull request, #4458: URL: https://github.com/apache/activemq-artemis/pull/4458 … callback handler Issue Time Tracking --- Worklog Id: (was: 859428) Remaining Estimate: 0h Time Spent: 10m > support access to our JaasCallbackhandler from a jdk http Authenticator > --- > > Key: ARTEMIS-4263 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4263 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > To allow the jolokia jvm agent to utilise jaas with our callback handler, it > is necessary to provide a wrapper that is aware of the capabilities of the > various artemis login modules and provide the necessary callback > implementation > Jolokia supports an externsion point in the form of a > com.sun.net.httpserver.Authenticator that we can use. > This will allow us to reduce the surface are that we expose to support > jolokia, avoiding the need for jetty. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4263) support access to our JaasCallbackhandler from a jdk http Authenticator
Gary Tully created ARTEMIS-4263: --- Summary: support access to our JaasCallbackhandler from a jdk http Authenticator Key: ARTEMIS-4263 URL: https://issues.apache.org/jira/browse/ARTEMIS-4263 Project: ActiveMQ Artemis Issue Type: Improvement Components: JAAS Affects Versions: 2.28.0 Reporter: Gary Tully Assignee: Gary Tully To allow the jolokia jvm agent to utilise jaas with our callback handler, it is necessary to provide a wrapper that is aware of the capabilities of the various artemis login modules and provide the necessary callback implementation Jolokia supports an externsion point in the form of a com.sun.net.httpserver.Authenticator that we can use. This will allow us to reduce the surface are that we expose to support jolokia, avoiding the need for jetty. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9252) java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)'
[ https://issues.apache.org/jira/browse/AMQ-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717268#comment-17717268 ] Robbie Gemmell commented on AMQ-9252: - JMS 2.0 incorporates all the JMS 1.1 APIs so support wasnt exactly 'dropped', its just that in this case you have mixed in the actual 1.1 API jar and the new impl isnt tolerant of that, though it could be made to be so with some changes. Simply remove the 1.1 spec jar for now and that will fix things. An application built against 1.1 will still work with the new (/10 year old) 2.0 spec jar. > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > -- > > Key: AMQ-9252 > URL: https://issues.apache.org/jira/browse/AMQ-9252 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.0 > Environment: ActiveMQ 5.18.0 > OpenJDK 11 > >Reporter: Marc Boorshtein >Priority: Major > > Getting this exception starting in 5.18: > > WARN JMSConnection - Could not send keep alive for openunisuron-tasks-1, > recreating > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > at > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1993) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:329) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:270) > ~[activemq-client-5.18.0.jar:5.18.0] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.sendKeepAliveMessage(JMSConnection.java:158) > [unison-sdk-1.0.34.jar:?] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.run(JMSConnection.java:129) > [unison-sdk-1.0.34.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > > this seems to be introduced from > [https://github.com/apache/activemq/commit/ead9533d5300fb2b5c48cfe70ef8b8fd84f46feb] > > this error is not consistent, it comes up randomly. Some runs, there are no > issues but others this error happens. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?focusedWorklogId=859416=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859416 ] ASF GitHub Bot logged work on ARTEMIS-3042: --- Author: ASF GitHub Bot Created on: 27/Apr/23 14:39 Start Date: 27/Apr/23 14:39 Worklog Time Spent: 10m Work Description: SamTV12345 commented on PR #4307: URL: https://github.com/apache/activemq-artemis/pull/4307#issuecomment-1525818660 The question is how minimal is the produced image? Could you create a docker-compose with a few steps that would satisfy the requirement for different base images? If we talk about a docker-compose yaml you also need suitable tooling in form of a docker compose cli plugin or v1 docker-compose. If you could easily switch between base images and select them by a build arg that would indeed be interesting. I am unfortunately currently pretty involved in other FOSS projects so if you could please go through creating said yaml I should be able to adapt the scripts and add the alpine image which was one of the reasons this pr exists. Issue Time Tracking --- Worklog Id: (was: 859416) Time Spent: 7.5h (was: 7h 20m) > Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 7.5h > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9252) java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)'
[ https://issues.apache.org/jira/browse/AMQ-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717245#comment-17717245 ] Marc Boorshtein commented on AMQ-9252: -- > This almost certainly means the JMS 1.1 API is on the classpath and taking > precedence Yes, looking at the classpath both JMS 1.1 and 2.0 libraries are there. It looks like the activemq client changed including it themselves from 5.17.1 --> 5.18.0. > The application should really avoid getting into this situation. The client > can also be tweaked so it handles it though. Dropping support for JMS 1.1 seems like much more then a point release change. > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > -- > > Key: AMQ-9252 > URL: https://issues.apache.org/jira/browse/AMQ-9252 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.0 > Environment: ActiveMQ 5.18.0 > OpenJDK 11 > >Reporter: Marc Boorshtein >Priority: Major > > Getting this exception starting in 5.18: > > WARN JMSConnection - Could not send keep alive for openunisuron-tasks-1, > recreating > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > at > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1993) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:329) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:270) > ~[activemq-client-5.18.0.jar:5.18.0] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.sendKeepAliveMessage(JMSConnection.java:158) > [unison-sdk-1.0.34.jar:?] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.run(JMSConnection.java:129) > [unison-sdk-1.0.34.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > > this seems to be introduced from > [https://github.com/apache/activemq/commit/ead9533d5300fb2b5c48cfe70ef8b8fd84f46feb] > > this error is not consistent, it comes up randomly. Some runs, there are no > issues but others this error happens. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=859410=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859410
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 13:52
Start Date: 27/Apr/23 13:52
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4456:
URL:
https://github.com/apache/activemq-artemis/pull/4456#issuecomment-1525735799
I couldn't complete the testsuite using this PR
Issue Time Tracking
---
Worklog Id: (was: 859410)
Time Spent: 5h 40m (was: 5.5h)
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717233#comment-17717233 ] ASF subversion and git services commented on AMQ-9239: -- Commit 6b277a49037fd886e4b1c969c8cff97add335dcd in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=6b277a490 ] [AMQ-9239] Host joram jms unit tests ahead of converting to jakarta.jms (#1002) Merging now for jakarta work, may backout later > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?focusedWorklogId=859409=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859409 ] ASF GitHub Bot logged work on AMQ-9239: --- Author: ASF GitHub Bot Created on: 27/Apr/23 13:37 Start Date: 27/Apr/23 13:37 Worklog Time Spent: 10m Work Description: mattrpav merged PR #1002: URL: https://github.com/apache/activemq/pull/1002 Issue Time Tracking --- Worklog Id: (was: 859409) Time Spent: 1h 50m (was: 1h 40m) > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9252) java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)'
[ https://issues.apache.org/jira/browse/AMQ-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717159#comment-17717159 ] Robbie Gemmell commented on AMQ-9252: - This almost certainly means the JMS 1.1 API is on the classpath and taking precedence, perhaps shifting position on the classpath between runs to explain the variation, and that the new partial-JMS-2.0 client isnt handling that while sending one of its own 2.0 messages, as it tried to call Message.setJMSDeliveryTime(long), which doesnt exist on the old Interface and so the JVM threw when the method wasnt found at runtime. The application should really avoid getting into this situation. The client can also be tweaked so it handles it though. > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > -- > > Key: AMQ-9252 > URL: https://issues.apache.org/jira/browse/AMQ-9252 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.0 > Environment: ActiveMQ 5.18.0 > OpenJDK 11 > >Reporter: Marc Boorshtein >Priority: Major > > Getting this exception starting in 5.18: > > WARN JMSConnection - Could not send keep alive for openunisuron-tasks-1, > recreating > java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)' > at > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1993) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:329) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) > ~[activemq-client-5.18.0.jar:5.18.0] > at > org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:270) > ~[activemq-client-5.18.0.jar:5.18.0] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.sendKeepAliveMessage(JMSConnection.java:158) > [unison-sdk-1.0.34.jar:?] > at > com.tremolosecurity.provisioning.jms.JMSConnection$2.run(JMSConnection.java:129) > [unison-sdk-1.0.34.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > > this seems to be introduced from > [https://github.com/apache/activemq/commit/ead9533d5300fb2b5c48cfe70ef8b8fd84f46feb] > > this error is not consistent, it comes up randomly. Some runs, there are no > issues but others this error happens. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4259) JMS topic + FQQN + filter not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?focusedWorklogId=859395=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859395
]
ASF GitHub Bot logged work on ARTEMIS-4259:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 11:42
Start Date: 27/Apr/23 11:42
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #4452:
URL:
https://github.com/apache/activemq-artemis/pull/4452#issuecomment-1525545220
More specifically, auto-created 'topic consumer + FQQN + filter' queues, and
expecting that only messages matching that consumers filter will get to the
created queue, and ultimately the consumer?
Looks like for Core, it didnt do any filtering at all for the auto-created
FQQN+filter case, as neither queue creation or consumer had a filter applied.
For AMQP, it looks like the consumers are filtered, but the queue wasnt and
thus would get all messages on the address and retain any that dont match the
consumer(s) filter(s). If a pre-created queue existed with an appropriate
filter, it seems like it would have worked for both.
This change looks like it fixes the auto-creation case, though seems like it
would introduce and/or retain some oddities for working with existing queues
either pre-defined or previously auto-created (plus may even prevent some niche
things that worked before).
For queues that already exist and that either have no filter or have a
different filter than a new consumer uses, it doesnt seem like it will be
noticed since nothing is done with the queue filter when the queue already
exists. For Core that seems like it could mean if the existing queue has no
filter it still does no filtering even when its desired it should , and for the
mismatched-filters case it might actually filter the 'wrong thing' and again
allow non-matching messages to get to the consumer, since it still looks to
rely solely on the hopefully-existing-and-hopefully-matching queue filter
alone, with no consumer filter put in place at all. For AMQP, it seems it could
once again pile up any messages that dont match the new consumers filter for
the no-existing-queue-filter case (since it will still get all messages but the
consumer will be filtered), and in the mismatched filter case it may not get
all messages it 'should' and may pile up unmatched messages again since the
queue filter doesnt match the consumers, though at least no 'non-matching'
messages would get to the consumer due to its filter (note it will often be
double-filtering though since both queue and consumer can have filters).
Its not clear to me what can/should be done about that. Document it and
ignore? Check if queue is filtered and throw if there is a mismatch (but that
might actually be deliberate for a pre-defined queue filter..)? (For regular
JMS durable subs the existing sub is to be seamlessly destroyed and a fresh sub
begun when filter changes..same for shared subs, if not currently in use by
others).
One thing is this could prevent some existing possible niche behaviours.
Previously it seems you could perhaps have had multiple filtered AMQP consumers
having different filters pulling from the same FQQN (say, structured such that
all messages could be consumed by someone). This will break such things for
auto-created usage, since the queue would now be filtered based only on the
first/creating consumers filter. JMS specifically doesnt allow such stuff with
regular shared subs though, everyone has to use same filter for this reason.
Issue Time Tracking
---
Worklog Id: (was: 859395)
Remaining Estimate: 0h
Time Spent: 10m
> JMS topic + FQQN + filter not working
> -
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer
[jira] [Work logged] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?focusedWorklogId=859390=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859390 ] ASF GitHub Bot logged work on ARTEMIS-3042: --- Author: ASF GitHub Bot Created on: 27/Apr/23 11:16 Start Date: 27/Apr/23 11:16 Worklog Time Spent: 10m Work Description: ViliusS commented on PR #4307: URL: https://github.com/apache/activemq-artemis/pull/4307#issuecomment-1525509798 I gave this more thought today. In theory, if the requirement is to just conveniently allow users to build docker image and run it locally there is a docker-compose exactly for that purpose. All prepare/run steps can be automated via Docker Compose YAML file. It also allows for better build and runtime separation. Issue Time Tracking --- Worklog Id: (was: 859390) Time Spent: 7h 20m (was: 7h 10m) > Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 7h 20m > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4245) Expose web SNI settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4245?focusedWorklogId=859372=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859372
]
ASF GitHub Bot logged work on ARTEMIS-4245:
---
Author: ASF GitHub Bot
Created on: 27/Apr/23 10:11
Start Date: 27/Apr/23 10:11
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4441:
URL: https://github.com/apache/activemq-artemis/pull/4441#discussion_r1178936369
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -283,6 +298,40 @@ public void simpleSecureServer() throws Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckEnabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(true);
+ }
+
+ @Test
+ public void testSimpleSecureServerWithSniHostCheckDisabled() throws
Exception {
+ testSimpleSecureServerWithSniHostCheck(false);
+ }
Review Comment:
Do we want to test the default behaviour is 'enabled' (i.e change the
boolean to Boolean and pass null as well)?
Currently nothing looks to be checking the default, since these 2 tests only
verify it succeeds/fails using the IP address when the setting was _explicitly_
disabled or enabled.
##
artemis-dto/src/main/java/org/apache/activemq/artemis/dto/BindingDTO.java:
##
@@ -181,6 +187,22 @@ public void addApp(AppDTO app) {
apps.add(app);
}
+ public Boolean getSniHostCheck() {
+ return sniHostCheck;
+ }
+
+ public void setSniHostCheck(Boolean sniHostCheck) {
+ this.sniHostCheck = sniHostCheck;
+ }
+
+ public Boolean getSniRequired() {
+ return sniRequired;
+ }
+
+ public void setSniRequired(Boolean sniRequired) {
+ this.sniRequired = sniRequired;
+ }
+
Review Comment:
org.apache.activemq.artemis.dto.test.BindingDTOTest.testDefault() should be
updated to check these are null by default since the new default behaviour
depends on it.
##
artemis-web/src/test/java/org/apache/activemq/cli/test/WebServerComponentTest.java:
##
@@ -215,11 +221,11 @@ public void testComponentStopStartBehavior() throws
Exception {
Assert.assertFalse(webServerComponent.isStarted());
}
- @Test
- public void simpleSecureServer() throws Exception {
+ private WebServerComponent startSimpleSecureServer(String keyStorePath,
String keyStorePassword, Boolean sniHostCheck) throws Exception {
BindingDTO bindingDTO = new BindingDTO();
bindingDTO.uri = "https://localhost:0;;
bindingDTO.keyStorePath = "./src/test/resources/server.keystore";
+ bindingDTO.setSniHostCheck(sniHostCheck);
Review Comment:
might be nice to only set it if non-null?
Issue Time Tracking
---
Worklog Id: (was: 859372)
Time Spent: 20m (was: 10m)
> Expose web SNI settings
> ---
>
> Key: ARTEMIS-4245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4245
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Expose sniHostCheck and sniRequired settings in the web config.
> {code:xml}
>
>http://localhost:8161; sniHostCheck="false"
> sniRequired="false">
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=859331=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859331 ] ASF GitHub Bot logged work on ARTEMIS-4251: --- Author: ASF GitHub Bot Created on: 27/Apr/23 07:08 Start Date: 27/Apr/23 07:08 Worklog Time Spent: 10m Work Description: brusdev commented on code in PR #4447: URL: https://github.com/apache/activemq-artemis/pull/4447#discussion_r1178713896 ## docs/user-manual/en/client-reconnection.md: ## @@ -89,9 +89,20 @@ Client reconnection is configured using the following parameters: ridiculously large values. By setting this parameter you can set an upper limit on that value. The default value is `2000` milliseconds. +- `ha`. This optional parameter determines weather the client will try to + reconnect to the backup node when the live node is not reachable. + The default value is `false`. + For more information on HA, please see [High Availability and Failover](ha.md). + - `reconnectAttempts`. This optional parameter determines the total number of - reconnect attempts to make before giving up and shutting down. A value of - `-1` signifies an unlimited number of attempts. The default value is `0`. + reconnect attempts to make to the current live/backup pair before giving up. Review Comment: @gtully @gemmellr thanks for your feedback, I'll review the doc and I'll move the pause between 2 consecutive failover retries after trying all available connectors. Issue Time Tracking --- Worklog Id: (was: 859331) Time Spent: 1h (was: 50m) > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=859329=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859329 ] ASF GitHub Bot logged work on ARTEMIS-4251: --- Author: ASF GitHub Bot Created on: 27/Apr/23 07:07 Start Date: 27/Apr/23 07:07 Worklog Time Spent: 10m Work Description: brusdev commented on code in PR #4447: URL: https://github.com/apache/activemq-artemis/pull/4447#discussion_r1178713896 ## docs/user-manual/en/client-reconnection.md: ## @@ -89,9 +89,20 @@ Client reconnection is configured using the following parameters: ridiculously large values. By setting this parameter you can set an upper limit on that value. The default value is `2000` milliseconds. +- `ha`. This optional parameter determines weather the client will try to + reconnect to the backup node when the live node is not reachable. + The default value is `false`. + For more information on HA, please see [High Availability and Failover](ha.md). + - `reconnectAttempts`. This optional parameter determines the total number of - reconnect attempts to make before giving up and shutting down. A value of - `-1` signifies an unlimited number of attempts. The default value is `0`. + reconnect attempts to make to the current live/backup pair before giving up. Review Comment: @gtully @gemmellr thanks for your feedback, I'll review the doc and I'll move the pause after trying all available connectors. Issue Time Tracking --- Worklog Id: (was: 859329) Time Spent: 50m (was: 40m) > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?focusedWorklogId=859321=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859321 ] ASF GitHub Bot logged work on ARTEMIS-3042: --- Author: ASF GitHub Bot Created on: 27/Apr/23 06:19 Start Date: 27/Apr/23 06:19 Worklog Time Spent: 10m Work Description: ViliusS commented on PR #4307: URL: https://github.com/apache/activemq-artemis/pull/4307#issuecomment-1524821751 > I think Docker multistage builds are great. I don't need to configure anything on the host machine and can simply press "build" in Jenkins. I don't argue that, but as I said, such images are great only for final deployment or local development. > Other than that you can still always customize the Dockerfile by cloning your own Dockerfile before docker build and replace the standard build with your own. I know that, however this PR changes the purpose of these Dockerfiles. Previously they contained only configuration needed for the runtime and served more as a tool to build your own custom images. Now they contain old the build flow inside, hence they now serve just as easier way to run Artemis. Issue Time Tracking --- Worklog Id: (was: 859321) Time Spent: 7h 10m (was: 7h) > Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 7h 10m > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
