[jira] [Closed] (ARTEMIS-4003) FlowControl on BridgeImpl is broken for Large Messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4003. --- Resolution: Fixed > FlowControl on BridgeImpl is broken for Large Messages > -- > > Key: ARTEMIS-4003 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4003 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.26.0 > > Time Spent: 40m > Remaining Estimate: 0h > > LargeMessages over BridgeImpl (including Clustering) will request more > credits eventually than what they are entitled. This is because we don't flow > control the large message producer on the Bridge (at least not yet), and the > sender could get to a window where it requested more credits than it was > entitled. The flow control on the Bridge is limited to handle returning busy > or not (and that should be enough really). > as a Result, the flow control will never refill and the bridge would freeze > and get stuck. > To fix this situation we should check for the starve at the end of the > receive credits and do the proper refill. > I am writing a test validating this issue, it will be under smokeTests and it > will be named > org.apache.activemq.artemis.tests.smoke.clusteredLargeMessage.ClusteredLargeMessageTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3928. --- Resolution: Fixed > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3999) Error setting extraParams for new acceptors via broker properties
[
https://issues.apache.org/jira/browse/ARTEMIS-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3999.
---
Resolution: Fixed
> Error setting extraParams for new acceptors via broker properties
> -
>
> Key: ARTEMIS-3999
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3999
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis 2.25.0 ignore extraParams provided via broker properties for
> new acceptors, i.e.
> {code}
> acceptorConfigurations.new.extraParams.supportAdvisory=true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3964) Windows ping IPv4/6 commands have wrong time unit
[
https://issues.apache.org/jira/browse/ARTEMIS-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3964.
---
Resolution: Fixed
> Windows ping IPv4/6 commands have wrong time unit
> -
>
> Key: ARTEMIS-3964
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3964
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ping command on Windows uses
> -w timeout Timeout in milliseconds to wait for each reply. while in code is
> used seconds.
> {code:java}
> String IPV6_DEFAULT_COMMAND = Env.isWindowsOs() ? "ping -n 1 -w %d %s" :
>
> // default int networkTimeout = 1000;
> long timeout = Math.max(1, TimeUnit.MILLISECONDS.toSeconds(networkTimeout));
> ...
> processBuilder = buildProcess(ipv6Command, timeout,
> address.getCanonicalHostName()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3918) Support FQQN + anycast + redistribution
[
https://issues.apache.org/jira/browse/ARTEMIS-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3918.
---
Resolution: Fixed
> Support FQQN + anycast + redistribution
> ---
>
> Key: ARTEMIS-3918
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3918
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When sending to and consuming from an FQQN on separate cluster nodes messages
> are not redistributed. This is fairly easy to reproduce.
> # Create a symmetric cluster of 2 nodes.
> # Start a producer connected to node 1 and send a bunch of messages
> {noformat}
> $ ./artemis producer --message-count 20 --destination 'myAddress::myQueue'
> --url tcp://node1:61616{noformat}
> # Start a consumer connected to node 2
> {noformat}
> $ ./artemis consumer --message-count 20 --destination 'myAddress::myQueue'
> --url tcp://node2:61616{noformat}
> No message is consumed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3900) Support management allowlist entries with wildcard domain
[ https://issues.apache.org/jira/browse/ARTEMIS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3900. --- Resolution: Fixed > Support management allowlist entries with wildcard domain > - > > Key: ARTEMIS-3900 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3900 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.25.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3961) Don't log OperationContext
[
https://issues.apache.org/jira/browse/ARTEMIS-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3961.
---
Resolution: Fixed
> Don't log OperationContext
> --
>
> Key: ARTEMIS-3961
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3961
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{org.apache.activemq.artemis.core.persistence.OperationContext}} is a
> low-level implementation detail and therefore not relevant for user logging.
> Furthermore,
> {{org.apache.activemq.artemis.core.persistence.impl.journal.OperationContextImpl#toString}}
> is not thread-safe. It should only be used by developers in very specific
> situations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3998) Error setting broker properties for connectionRouters
[
https://issues.apache.org/jira/browse/ARTEMIS-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3998.
---
Resolution: Fixed
> Error setting broker properties for connectionRouters
> -
>
> Key: ARTEMIS-3998
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3998
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis 2.25.0 raise the following exception when it load broker
> properties for connectionRouters:
> {code}
> connectionRouters.autoShard.keyType=CLIENT_ID
> connectionRouters.autoShard.localTargetFilter=NULL|${STATEFUL_SET_ORDINAL}|-${STATEFUL_SET_ORDINAL}
> connectionRouters.autoShard.policyConfiguration=CONSISTENT_HASH_MODULO
> connectionRouters.autoShard.policyConfiguration.properties.MODULO=2
> acceptorConfigurations.tcp.params.router=autoShard
> addressesSettings."LB.#".defaultAddressRoutingType=ANYCAST
> {code}
> {code:java}
> ERROR [org.apache.activemq.artemis.core.server] AMQ224097: Failed to start
> server: java.lang.IllegalArgumentException: failed to locate add method for
> collection property addConnectionRouter
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl$CollectionAutoFillPropertiesUtil.newNamedInstanceForCollection(ConfigurationImpl.java:2998)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl$CollectionAutoFillPropertiesUtil.getProperty(ConfigurationImpl.java:2871)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:896)
> [commons-beanutils-1.9.4.jar:1.9.4]
> at
> org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:823)
> [commons-beanutils-1.9.4.jar:1.9.4]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.populateWithProperties(ConfigurationImpl.java:587)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parsePrefixedProperties(ConfigurationImpl.java:531)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parseProperties(ConfigurationImpl.java:501)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:618)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:579)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:64)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:127)
> [artemis-cli-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:160)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:108)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:135)
> [artemis-cli-2.25.0.jar:2.25.0]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) [java.base:]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> [java.base:]
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java.base:]
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> [java.base:]
> at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:134)
> [artemis-boot.jar:2.25.0]
> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:50)
> [artemis-boot.jar:2.25.0]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3929) Changing OpenWireProtocolManager::clientIDs to a concurrent Hash Map
[ https://issues.apache.org/jira/browse/ARTEMIS-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3929. --- Resolution: Fixed > Changing OpenWireProtocolManager::clientIDs to a concurrent Hash Map > > > Key: ARTEMIS-3929 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3929 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > > as I was testing ARTEMIS-3928 I found this contention with the clientID > hashMap, what was causing the entire broker to freeze when every client was > failing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4010) LegacyLDAPSecuritySettingPlugin missing data
[ https://issues.apache.org/jira/browse/ARTEMIS-4010 ] Robbie Gemmell deleted comment on ARTEMIS-4010: - was (Author: jira-bot): Commit 9d7d36f0005b621b407c0d718b60cd6e28dd2613 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9d7d36f000 ] ARTEMIS-4010 LegacyLDAPSecuritySettingPlugin missing data In commit a9a85f98db4f49d633541069ae997b4d099837e3 I removed the code which modified existing matches. However, I forgot that the matches read from LDAP are often duplicated so instead of always adding a new match this commit ensures that the *right* match is modified rather than a potentially more generic wildcard match (which was the original problem). (cherry picked from commit e47b7992cae3e3449225da5d04d78c2254acd2fc) downstream: ENTMQBR-7118 > LegacyLDAPSecuritySettingPlugin missing data > > > Key: ARTEMIS-4010 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4010 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4024) Avoid excessive NativeMemory allocation when sending OpenWire Multi mega sized messages in openwire
[ https://issues.apache.org/jira/browse/ARTEMIS-4024 ] Robbie Gemmell deleted comment on ARTEMIS-4024: - was (Author: jira-bot): Commit 23d6f19080835c57d917375ca1e5d16afe31fe43 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=23d6f19080 ] ARTEMIS-4024 Avoid excessive NativeMemory allocation when sending OpenWire Multi mega sized messages in openwire (cherry picked from commit 18cfdb7049ca90e5c5a08611413f6ba5d60152ff) (cherry picked from commit 20fde76e99c040abafe6aecd8c22ddcb201fd8a4) downstream: ENTMQBR-7204 > Avoid excessive NativeMemory allocation when sending OpenWire Multi mega > sized messages in openwire > --- > > Key: ARTEMIS-4024 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4024 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > when sending a large message in openwire, we will read the entire file on the > memory, make the conversion from core, and send it on net > throughOpenWireProtocolManager::sendPhisical. > Such allocation should be limited and be sent in chunks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3998) Error setting broker properties for connectionRouters
[ https://issues.apache.org/jira/browse/ARTEMIS-3998 ]
Robbie Gemmell deleted comment on ARTEMIS-3998:
-
was (Author: jira-bot):
Commit 15f445e74ec222be92210a47510d15ae91e8a5db in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Domenico Francesco Bruscino
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=15f445e74e ]
ARTEMIS-3998 Fix broker properties for connectionRouters
(cherry picked from commit fda7f6ba379ec2f05be7d26524cc18f41b7e56fb)
downstream: ENTMQBR-6980
> Error setting broker properties for connectionRouters
> -
>
> Key: ARTEMIS-3998
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3998
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis 2.25.0 raise the following exception when it load broker
> properties for connectionRouters:
> {code}
> connectionRouters.autoShard.keyType=CLIENT_ID
> connectionRouters.autoShard.localTargetFilter=NULL|${STATEFUL_SET_ORDINAL}|-${STATEFUL_SET_ORDINAL}
> connectionRouters.autoShard.policyConfiguration=CONSISTENT_HASH_MODULO
> connectionRouters.autoShard.policyConfiguration.properties.MODULO=2
> acceptorConfigurations.tcp.params.router=autoShard
> addressesSettings."LB.#".defaultAddressRoutingType=ANYCAST
> {code}
> {code:java}
> ERROR [org.apache.activemq.artemis.core.server] AMQ224097: Failed to start
> server: java.lang.IllegalArgumentException: failed to locate add method for
> collection property addConnectionRouter
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl$CollectionAutoFillPropertiesUtil.newNamedInstanceForCollection(ConfigurationImpl.java:2998)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl$CollectionAutoFillPropertiesUtil.getProperty(ConfigurationImpl.java:2871)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:896)
> [commons-beanutils-1.9.4.jar:1.9.4]
> at
> org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:823)
> [commons-beanutils-1.9.4.jar:1.9.4]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.populateWithProperties(ConfigurationImpl.java:587)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parsePrefixedProperties(ConfigurationImpl.java:531)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parseProperties(ConfigurationImpl.java:501)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:618)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:579)
> [artemis-server-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:64)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:127)
> [artemis-cli-2.25.0.jar:2.25.0]
> at
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:160)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:108)
> [artemis-cli-2.25.0.jar:2.25.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:135)
> [artemis-cli-2.25.0.jar:2.25.0]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) [java.base:]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> [java.base:]
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java.base:]
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> [java.base:]
> at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:134)
> [artemis-boot.jar:2.25.0]
> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:50)
> [artemis-boot.jar:2.25.0]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-4003) FlowControl on BridgeImpl is broken for Large Messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4003 ] Robbie Gemmell deleted comment on ARTEMIS-4003: - was (Author: jira-bot): Commit dea436641922ddc51941886fd931edc0debfb1a9 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=dea4366419 ] ARTEMIS-4003 Fixing credit starve on Large Message over the bridge or clustering (cherry picked from commit 7bf1193380c8b15d8f5d0f14bd028e2380b104d6) downstream: ENTMQBR-6891 > FlowControl on BridgeImpl is broken for Large Messages > -- > > Key: ARTEMIS-4003 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4003 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.26.0 > > Time Spent: 40m > Remaining Estimate: 0h > > LargeMessages over BridgeImpl (including Clustering) will request more > credits eventually than what they are entitled. This is because we don't flow > control the large message producer on the Bridge (at least not yet), and the > sender could get to a window where it requested more credits than it was > entitled. The flow control on the Bridge is limited to handle returning busy > or not (and that should be enough really). > as a Result, the flow control will never refill and the bridge would freeze > and get stuck. > To fix this situation we should check for the starve at the end of the > receive credits and do the proper refill. > I am writing a test validating this issue, it will be under smokeTests and it > will be named > org.apache.activemq.artemis.tests.smoke.clusteredLargeMessage.ClusteredLargeMessageTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3961) Don't log OperationContext
[ https://issues.apache.org/jira/browse/ARTEMIS-3961 ]
Robbie Gemmell deleted comment on ARTEMIS-3961:
-
was (Author: jira-bot):
Commit 9eefb74da27263bf7f0929e63d1521396ef84032 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9eefb74da2 ]
ARTEMIS-3961 don't log OperationContext
(cherry picked from commit 0e56d1a567a99ecba7ae3836c81a807309132cd8)
downstream: ENTMQBR-7089, ENTMQBR-7067
> Don't log OperationContext
> --
>
> Key: ARTEMIS-3961
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3961
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{org.apache.activemq.artemis.core.persistence.OperationContext}} is a
> low-level implementation detail and therefore not relevant for user logging.
> Furthermore,
> {{org.apache.activemq.artemis.core.persistence.impl.journal.OperationContextImpl#toString}}
> is not thread-safe. It should only be used by developers in very specific
> situations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3900) Support management allowlist entries with wildcard domain
[ https://issues.apache.org/jira/browse/ARTEMIS-3900 ] Robbie Gemmell deleted comment on ARTEMIS-3900: - was (Author: jira-bot): Commit 4f1f4c28ebe87d3a441843cef492678bdf85a596 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4f1f4c28eb ] ARTEMIS-3900 Support management allowlist entries with wildcard domain (cherry picked from commit d250801fcf27ff08e9ac6ad51b081d7be8f894cf) downstream: ENTMQBR-6779 > Support management allowlist entries with wildcard domain > - > > Key: ARTEMIS-3900 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3900 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.25.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3964) Windows ping IPv4/6 commands have wrong time unit
[ https://issues.apache.org/jira/browse/ARTEMIS-3964 ]
Robbie Gemmell deleted comment on ARTEMIS-3964:
-
was (Author: jira-bot):
Commit 3a1ec7f155181d4c2eeb6e13c96060b0be1f8b41 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Domenico Francesco Bruscino
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3a1ec7f155 ]
ARTEMIS-3964 Fix default ping commands timeout for Windows
The ping command on Windows uses -w timeout in milliseconds.
(cherry picked from commit 90966ccdf1704aad12df913c7e18fd9e5846166a)
downstream: ENTMQBR-7072
> Windows ping IPv4/6 commands have wrong time unit
> -
>
> Key: ARTEMIS-3964
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3964
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ping command on Windows uses
> -w timeout Timeout in milliseconds to wait for each reply. while in code is
> used seconds.
> {code:java}
> String IPV6_DEFAULT_COMMAND = Env.isWindowsOs() ? "ping -n 1 -w %d %s" :
>
> // default int networkTimeout = 1000;
> long timeout = Math.max(1, TimeUnit.MILLISECONDS.toSeconds(networkTimeout));
> ...
> processBuilder = buildProcess(ipv6Command, timeout,
> address.getCanonicalHostName()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3999) Error setting extraParams for new acceptors via broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-3999 ]
Robbie Gemmell deleted comment on ARTEMIS-3999:
-
was (Author: jira-bot):
Commit 85ddbe3bceab0db0b1c1201c0cfe190f5b7c9998 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Domenico Francesco Bruscino
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=85ddbe3bce ]
ARTEMIS-3999 Fix setting extraParams for new acceptors via broker properties
(cherry picked from commit 93a5f3b596a6d4a394bc78f7edf8774c37cdee5c)
downstream: ENTMQBR-7123
> Error setting extraParams for new acceptors via broker properties
> -
>
> Key: ARTEMIS-3999
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3999
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis 2.25.0 ignore extraParams provided via broker properties for
> new acceptors, i.e.
> {code}
> acceptorConfigurations.new.extraParams.supportAdvisory=true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3947) Expiry settings not merging properly
[ https://issues.apache.org/jira/browse/ARTEMIS-3947 ]
Robbie Gemmell deleted comment on ARTEMIS-3947:
-
was (Author: jira-bot):
Commit 5be1ea859913659cade6aa132aa2d999f4004844 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=5be1ea8599 ]
ARTEMIS-3947 fix merging for expiry address-settings
(cherry picked from commit f1c9e3df1415bbde0c93cd2960991517bcd83ce3)
downstream: ENTMQBR-6695
> Expiry settings not merging properly
>
>
> Key: ARTEMIS-3947
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3947
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.24.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Setting {{expiry-delay}} in {{}} doesn't work if
> we set another property aside from {{expiry-delay}} and don't set
> {{expiry-delay}} in a specific match.
> *Test 1 - Fails*
> {code:xml}
>
> 4
>
>
> 12428800
> {code}
> Result: When I send a message to a queue on {{myAddress}} using the default
> expiration time (0 meaning don't expire), the broker doesn't change the
> expiration time to 40 seconds. *Messages never expire.*
> *Test 2 - OK*
> {code:xml}
>
> 4
>
>
> 6
> {code}
> Result: When I send a message to a queue on {{myAddress}} using the default
> expiration time (0 meaning don't expire) the broker changes the expiration
> time to 60 seconds.
> *Test 3 - OK*
> {code:xml}
>
> 4
> {code}
> Result: When I send a message to a queue on {{myAddress}} using the default
> expiration time (0 meaning don't expire) the broker changes the expiration
> time to 40 seconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3984) LegacyLDAPSecuritySettingPlugin shouldn't modify existing matches
[ https://issues.apache.org/jira/browse/ARTEMIS-3984 ]
Robbie Gemmell deleted comment on ARTEMIS-3984:
-
was (Author: jira-bot):
Commit 2d4e091801e5880380fb65f8c0287ec6317118a8 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2d4e091801 ]
ARTEMIS-3984 LegacyLDAPSecuritySettingPlugin shouldn't modify existing matches
When the LegacyLDAPSecuritySettingPlugin has enableListener set to true
and a new permission is added it will try to modify the existing match
if one exists. This is problematic if there's a more generic wildcard
match than the specific one that's modified.
This commit fixes that problem so that instead of modifying the existing
match(es) it simply adds a new one. The plugin never should have tried
modifying the existing match in the first place as two identical matches
would be a configuration error.
(cherry picked from commit a9a85f98db4f49d633541069ae997b4d099837e3)
downstream: ENTMQBR-7118
> LegacyLDAPSecuritySettingPlugin shouldn't modify existing matches
> -
>
> Key: ARTEMIS-3984
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3984
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the LegacyLDAPSecuritySettingPlugin has {{enableListener}} set to
> {{true}} and a new permission is added it will try to modify the existing
> match if one exists. This is problematic if there's a more generic wildcard
> match than the specific one that's modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit be714170d91d4d100b4182bf41d11afbaa6a47f4 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=be714170d9 ] ARTEMIS-3928/ENTMQBR-6797 Fixing the build after test looked for method only available upstream > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit 8fedaadf666b16ef5c7ff8d32b8d5f7f8ec9f54e in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8fedaadf66 ] ARTEMIS-3928 Fixing yield and shutdownNow Re-applying proper logic for yield and shutdownNow on Executors downstream: ENTMQBR-6797, ENTMQBR-6995 > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3918) Support FQQN + anycast + redistribution
[ https://issues.apache.org/jira/browse/ARTEMIS-3918 ]
Robbie Gemmell deleted comment on ARTEMIS-3918:
-
was (Author: jira-bot):
Commit a02935982e0b577afa3901e628d63394a5a9f1f4 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a02935982e ]
ARTEMIS-3918 support FQQN + anycast + redistribution
When a message is sent to an anycast queue via FQQN on one node of a
cluster and then a consumer is created on that same anycast queue via
FQQN on another node in the cluster the message is not redistributed to
the node with the consumer.
This commit fixes this use-case primarily by including the FQQN info in
the notification messages sent to other nodes in the cluster.
(cherry picked from commit 477111ef4c6d9cfbf0f83ca91222d6169405072f)
downstream: ENTMQBR-6673
> Support FQQN + anycast + redistribution
> ---
>
> Key: ARTEMIS-3918
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3918
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When sending to and consuming from an FQQN on separate cluster nodes messages
> are not redistributed. This is fairly easy to reproduce.
> # Create a symmetric cluster of 2 nodes.
> # Start a producer connected to node 1 and send a bunch of messages
> {noformat}
> $ ./artemis producer --message-count 20 --destination 'myAddress::myQueue'
> --url tcp://node1:61616{noformat}
> # Start a consumer connected to node 2
> {noformat}
> $ ./artemis consumer --message-count 20 --destination 'myAddress::myQueue'
> --url tcp://node2:61616{noformat}
> No message is consumed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit fc8a9b952c40ee190f7bfd9f15c0f4af12cb45c7 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fc8a9b952c ] ARTEMIS-3929 Improving OpenWire clientIDSet I have seen this contention while I was testing ARTEMIS-3928 This does change any semantics and current tests should be enough to validate this change (cherry picked from commit 568eb70fcda9737b38871a3bff1e111bad784091) downstream: ENTMQBR-7051 > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit ae0d654aae9211d5ff0504aed6b3c465dc7d80a7 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ae0d654aae ] ARTEMIS-3928 Adding SoakTest for Paging with in many destinations Also some organization on soak test to allow this test adding CLI operation to configure memory size of the broker (cherry picked from commit 12b81e7a256b1982fafc7e1090134ea1b44d451b) (cherry picked from commit bbe958985667dd02effc0a735f8d1f09a146ad31) downstream: ENTMQBR-6797, ENTMQBR-6995 > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit edc3355b816790b74a8ed0d5f11d350e6ba1c82c in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=edc3355b81 ] ARTEMIS-3928 Limiting parallel IO in paging which would allow multiple destinations running all at once Running HorizontalPagingTest with these variables would make the test to fail unless these changes are applied. export TEST_HORIZONTAL_SERVER_START_TIMEOUT=30 export TEST_HORIZONTAL_TIMEOUT_MINUTES=120 export TEST_HORIZONTAL_PROTOCOL_LIST=OPENWIRE export TEST_HORIZONTAL_OPENWIRE_DESTINATIONS=200 export TEST_HORIZONTAL_OPENWIRE_MESSAGES=1000 export TEST_HORIZONTAL_OPENWIRE_COMMIT_INTERVAL=100 export TEST_HORIZONTAL_OPENWIRE_RECEIVE_COMMIT_INTERVAL=0 export TEST_HORIZONTAL_OPENWIRE_MESSAGE_SIZE=2 export TEST_HORIZONTAL_OPENWIRE_PARALLEL_SENDS=10 (cherry picked from commit 252e5b0b14231d80de6829e4cc5d5fc1a2df1ac1) this is a partial cherry-pick, I am only picking changes that will limit the number of concurrent threads executing paging reading. The flow control changes will only apply if you had the cache removal in place. downstream: ENTMQBR-6797, ENTMQBR-6995 > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit 9c471185d1789e4a8b720985cd01157ea2117a27 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9c471185d1 ] ARTEMIS-3928 Reverting fairness on Executor > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3928) Paging will flood memory with Native Buffers if too many destinations are used at once
[ https://issues.apache.org/jira/browse/ARTEMIS-3928 ] Robbie Gemmell deleted comment on ARTEMIS-3928: - was (Author: jira-bot): Commit 2166fa86542284635ef3bfcdffa8b6e950d1deaa in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2166fa8654 ] ARTEMIS-3928 Fixing intermittent failure after executor's change (cherry picked from commit 2fbf2fcef0f97e4278dd4bc7b9c40aba8b53ea5a) downstream: ENTMQBR-6797, ENTMQBR-6995 > Paging will flood memory with Native Buffers if too many destinations are > used at once > -- > > Key: ARTEMIS-3928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3928 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.24.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There should be an IO limiter on the number of concurrent readings for Paging. > Also if openwire is in use, there's no flow control what will also flood the > queues with too much data and the broker will also OME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3963) Error setting security roles via properties on OpenJ9 JDK 11
[ https://issues.apache.org/jira/browse/ARTEMIS-3963 ]
Robbie Gemmell deleted comment on ARTEMIS-3963:
-
was (Author: jira-bot):
Commit b49bc5818336c9bc208aafcc340da7d48da262a8 in activemq-artemis's branch
refs/heads/2.21.0.jbossorg-x from Domenico Francesco Bruscino
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b49bc58183 ]
ARTEMIS-3963 Fix setting security roles via properties on OpenJ9 JDK 11
RoleSet.class.getMethods() returns the same methods on both OpenJDK 11 and
OpenJ9 JDK 11 but the order is different. OpenJDK 11 returns
`public void org.apache.activemq.artemis.core.config.impl.RoleSet.add` before
`public boolean java.util.HashSet.add` while OpenJ9 JDK 11 returns
`public boolean java.util.HashSet.add` before
`public void org.apache.activemq.artemis.core.config.impl.RoleSet.add`
(cherry picked from commit 45a1245cb0cf823495ef69df352e190dc94e10cd)
downstream: ENTMQBR-6980
> Error setting security roles via properties on OpenJ9 JDK 11
>
>
> Key: ARTEMIS-3963
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3963
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.24.0
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ConfigurationImplTest.testRoleSettingsViaProperties test fails on OpenJ9
> JDK 11:
> {code:java}
> java.lang.ClassCastException: java.lang.Object incompatible with
> org.apache.activemq.artemis.core.security.Role
> at
> org.apache.activemq.artemis.core.config.impl.ConfigurationImplTest.testRoleSettingsViaProperties(ConfigurationImplTest.java:927)
> {code}
> I see RoleSet.class.getMethods() returns the same methods on both OpenJDK 11
> and OpenJ9 JDK 11 but the order is different
> OpenJDK 11 returns `public void
> org.apache.activemq.artemis.core.config.impl.RoleSet.add(java.lang.String,org.apache.activemq.artemis.core.security.Role)`
> before `public boolean java.util.HashSet.add(java.lang.Object) `
> while OpenJ9 JDK 11 returns `public boolean
> java.util.HashSet.add(java.lang.Object)` before `public void
> org.apache.activemq.artemis.core.config.impl.RoleSet.add(java.lang.String,org.apache.activemq.artemis.core.security.Role)`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (ARTEMIS-3929) Changing OpenWireProtocolManager::clientIDs to a concurrent Hash Map
[ https://issues.apache.org/jira/browse/ARTEMIS-3929 ] Robbie Gemmell deleted comment on ARTEMIS-3929: - was (Author: jira-bot): Commit fc8a9b952c40ee190f7bfd9f15c0f4af12cb45c7 in activemq-artemis's branch refs/heads/2.21.0.jbossorg-x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fc8a9b952c ] ARTEMIS-3929 Improving OpenWire clientIDSet I have seen this contention while I was testing ARTEMIS-3928 This does change any semantics and current tests should be enough to validate this change (cherry picked from commit 568eb70fcda9737b38871a3bff1e111bad784091) downstream: ENTMQBR-7051 > Changing OpenWireProtocolManager::clientIDs to a concurrent Hash Map > > > Key: ARTEMIS-3929 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3929 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.25.0 > > > as I was testing ARTEMIS-3928 I found this contention with the clientID > hashMap, what was causing the entire broker to freeze when every client was > failing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (ARTEMIS-4020) switch to using SLF4J for logging API and use Log4j 2 for broker distribution
[ https://issues.apache.org/jira/browse/ARTEMIS-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-4020 started by Robbie Gemmell. --- > switch to using SLF4J for logging API and use Log4j 2 for broker distribution > - > > Key: ARTEMIS-4020 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4020 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.27.0 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Switch to using [SLF4J|https://www.slf4j.org/] as the logging API for the > code base, with end-uses supplying and configuring an SLF4J-supporting > logging implementation of their choice based on their needs. > For the client, applications will need to supply an SLF4J binding to a > logging implementation of their choice to enable logging. An example of doing > so using [Log4J 2|https://logging.apache.org/log4j/2.x/manual/index.html] is > given in (/will be, once the release is out) the [client logging > documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html#logging-in-a-client-application]. > For the broker, the assembly distribution will include [Log4J > 2|https://logging.apache.org/log4j/2.x/manual/index.html] as its logging > implentation, with the "artemis create" CLI command used to create broker > instances now creating a log4j2.properties configuration within the > /etc/ directory to configure Log4J. Details for upgrading an > existing broker-instance is given in (/will be, once the release is out) the > [version upgrade > documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3902) Adding reason for Security failure on Audit Security Message
[ https://issues.apache.org/jira/browse/ARTEMIS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3902. - Resolution: Fixed > Adding reason for Security failure on Audit Security Message > - > > Key: ARTEMIS-3902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3902 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Minor > Fix For: 2.27.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3902) Adding reason for Security failure on Audit Security Message
[ https://issues.apache.org/jira/browse/ARTEMIS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3902: Priority: Minor (was: Major) > Adding reason for Security failure on Audit Security Message > - > > Key: ARTEMIS-3902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3902 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Minor > Fix For: 2.27.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3902) Adding reason for Security failure on Audit Security Message
[ https://issues.apache.org/jira/browse/ARTEMIS-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612546#comment-17612546 ] Robbie Gemmell commented on ARTEMIS-3902: - The first 2 commits on main added and reverted the change some time ago. The third commit (which no longer actually exists) seems to have made the change on the new-logging branch, so its effect ended up as part of the initial commit on main for ARTEMIS-4020 towards 2.27.0. > Adding reason for Security failure on Audit Security Message > - > > Key: ARTEMIS-3902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3902 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.27.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-3902) Adding reason for Security failure on Audit Security Message
[ https://issues.apache.org/jira/browse/ARTEMIS-3902 ] Robbie Gemmell deleted comment on ARTEMIS-3902: - was (Author: jira-bot): Commit 47a66ec9ffbd5b54a1708a443e1058c16db95f22 in activemq-artemis's branch refs/heads/new-logging from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=47a66ec9ff ] ARTEMIS-3902 Adding Reason to Security Exception > Adding reason for Security failure on Audit Security Message > - > > Key: ARTEMIS-3902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3902 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.27.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4026) fix a couple of logging errors in connection-router classes
[ https://issues.apache.org/jira/browse/ARTEMIS-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4026. - Resolution: Fixed > fix a couple of logging errors in connection-router classes > --- > > Key: ARTEMIS-4026 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4026 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.26.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.27.0 > > > The 'LocalCache' class has some debug detail outputting the toString of an > object directly as an info log statement, and the 'LeastConnectionsPolicy' is > logging an incorrect value in a debug message (c&p error, its identical to > one just prior to it when it should differ slightly). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4026) fix a couple of logging errors in connection-router classes
Robbie Gemmell created ARTEMIS-4026: --- Summary: fix a couple of logging errors in connection-router classes Key: ARTEMIS-4026 URL: https://issues.apache.org/jira/browse/ARTEMIS-4026 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 2.26.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.27.0 The 'LocalCache' class has some debug detail outputting the toString of an object directly as an info log statement, and the 'LeastConnectionsPolicy' is logging an incorrect value in a debug message (c&p error, its identical to one just prior to it when it should differ slightly). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4020) switch to using SLF4J for logging API and use Log4j 2 for broker distribution
[ https://issues.apache.org/jira/browse/ARTEMIS-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611263#comment-17611263 ] Robbie Gemmell commented on ARTEMIS-4020: - Various reasons. First those elements were all done before 2.x was released. Next when I tried it I found Log4J 2.19.0 has a stupid bug (LOG4J2-3601) that makes it more awkward than needed. It also breaks the osgi related bits so isnt as simple as it might seem, and I didnt feel that trying to mix the two versions to work around that was worthwhile currently. Lastly, it isnt a massively pressing concern, since anyone will be able to exchange the SLF4J 1.x dep for 2.x in their [non-osgi] usage if they want to at runtime, they are compatible https://www.slf4j.org/faq.html#changesInVersion200. > switch to using SLF4J for logging API and use Log4j 2 for broker distribution > - > > Key: ARTEMIS-4020 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4020 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.27.0 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > Switch to using [SLF4J|https://www.slf4j.org/] as the logging API for the > code base, with end-uses supplying and configuring an SLF4J-supporting > logging implementation of their choice based on their needs. > For the client, applications will need to supply an SLF4J binding to a > logging implementation of their choice to enable logging. An example of doing > so using [Log4J 2|https://logging.apache.org/log4j/2.x/manual/index.html] is > given in (/will be, once the release is out) the [client logging > documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html#logging-in-a-client-application]. > For the broker, the assembly distribution will include [Log4J > 2|https://logging.apache.org/log4j/2.x/manual/index.html] as its logging > implentation, with the "artemis create" CLI command used to create broker > instances now creating a log4j2.properties configuration within the > /etc/ directory to configure Log4J. Details for upgrading an > existing broker-instance is given in (/will be, once the release is out) the > [version upgrade > documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4020) switch to using SLF4J for logging API and use Log4j 2 for broker distribution
[ https://issues.apache.org/jira/browse/ARTEMIS-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610500#comment-17610500 ] Robbie Gemmell commented on ARTEMIS-4020: - Original discussion: [https://lists.apache.org/thread/wq42fox0ck59n8tzvn21cfqlgjrrb6zl] > switch to using SLF4J for logging API and use Log4j 2 for broker distribution > - > > Key: ARTEMIS-4020 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4020 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.27.0 > > > Switch to using [SLF4J|https://www.slf4j.org/] as the logging API for the > code base, with end-uses supplying and configuring an SLF4J-supporting > logging implementation of their choice based on their needs. > For the client, applications will need to supply an SLF4J binding to a > logging implementation of their choice to enable logging. An example of doing > so using [Log4J 2|https://logging.apache.org/log4j/2.x/manual/index.html] is > given in (/will be, once the release is out) the [client logging > documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html#logging-in-a-client-application]. > For the broker, the assembly distribution will include [Log4J > 2|https://logging.apache.org/log4j/2.x/manual/index.html] as its logging > implentation, with the "artemis create" CLI command used to create broker > instances now creating a log4j2.properties configuration within the > /etc/ directory to configure Log4J. Details for upgrading an > existing broker-instance is given in (/will be, once the release is out) the > [version upgrade > documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4020) switch to using SLF4J for logging API and use Log4j 2 for broker distribution
Robbie Gemmell created ARTEMIS-4020: --- Summary: switch to using SLF4J for logging API and use Log4j 2 for broker distribution Key: ARTEMIS-4020 URL: https://issues.apache.org/jira/browse/ARTEMIS-4020 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Robbie Gemmell Fix For: 2.27.0 Switch to using [SLF4J|https://www.slf4j.org/] as the logging API for the code base, with end-uses supplying and configuring an SLF4J-supporting logging implementation of their choice based on their needs. For the client, applications will need to supply an SLF4J binding to a logging implementation of their choice to enable logging. An example of doing so using [Log4J 2|https://logging.apache.org/log4j/2.x/manual/index.html] is given in (/will be, once the release is out) the [client logging documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html#logging-in-a-client-application]. For the broker, the assembly distribution will include [Log4J 2|https://logging.apache.org/log4j/2.x/manual/index.html] as its logging implentation, with the "artemis create" CLI command used to create broker instances now creating a log4j2.properties configuration within the /etc/ directory to configure Log4J. Details for upgrading an existing broker-instance is given in (/will be, once the release is out) the [version upgrade documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4008) Update to Qpid JMS 1.7.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4008. - Resolution: Fixed > Update to Qpid JMS 1.7.0 > > > Key: ARTEMIS-4008 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4008 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4008) Update to Qpid JMS 1.7.0
Robbie Gemmell created ARTEMIS-4008: --- Summary: Update to Qpid JMS 1.7.0 Key: ARTEMIS-4008 URL: https://issues.apache.org/jira/browse/ARTEMIS-4008 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.26.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3970) update keycloak used in example to 19.0.2
[ https://issues.apache.org/jira/browse/ARTEMIS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3970: Summary: update keycloak used in example to 19.0.2 (was: update keycloak used in example to 19.0.1) > update keycloak used in example to 19.0.2 > - > > Key: ARTEMIS-3970 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3970 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3970) update keycloak used in example to 19.0.1
[ https://issues.apache.org/jira/browse/ARTEMIS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3970: Fix Version/s: 2.26.0 (was: 3.0.0) > update keycloak used in example to 19.0.1 > - > > Key: ARTEMIS-3970 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3970 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4006) remove '-all' repackaged clients from the assembly
[ https://issues.apache.org/jira/browse/ARTEMIS-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4006. - Assignee: Robbie Gemmell Resolution: Fixed > remove '-all' repackaged clients from the assembly > --- > > Key: ARTEMIS-4006 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4006 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > > The build has 3 'uber client' modules that repackages the client > dependencies, and shades some of them. 2 of these are currently in the > assembly, artemis-jms-client-all, and artemis-jakarta-client-all. This means > the client dependencies are all duplicated and exist 3 times within the > assembly, with everyone downloading 2 (or 3) clients worth of deps they > probably wont use (from either the original individual client deps, or the > repackaged uber ones which are mutually exclusive). > As a compromise over removing these modules entirely, removing these from the > assembly would reduce the assembly size for everyone (by ~17MB or 1/3rd of > the libs dir), and remain simple for folks that may actually want such an > artifact to retrieve the single specific client in isolation from maven > central (which the documentation already covers). > https://lists.apache.org/thread/hczsb2h6mgmo6xxcp9qv8313x75cxx3d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4006) remove '-all' repackaged clients from the assembly
Robbie Gemmell created ARTEMIS-4006: --- Summary: remove '-all' repackaged clients from the assembly Key: ARTEMIS-4006 URL: https://issues.apache.org/jira/browse/ARTEMIS-4006 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Fix For: 2.26.0 The build has 3 'uber client' modules that repackages the client dependencies, and shades some of them. 2 of these are currently in the assembly, artemis-jms-client-all, and artemis-jakarta-client-all. This means the client dependencies are all duplicated and exist 3 times within the assembly, with everyone downloading 2 (or 3) clients worth of deps they probably wont use (from either the original individual client deps, or the repackaged uber ones which are mutually exclusive). As a compromise over removing these modules entirely, removing these from the assembly would reduce the assembly size for everyone (by ~17MB or 1/3rd of the libs dir), and remain simple for folks that may actually want such an artifact to retrieve the single specific client in isolation from maven central (which the documentation already covers). https://lists.apache.org/thread/hczsb2h6mgmo6xxcp9qv8313x75cxx3d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4005) e2e-tests module is broken due Dockerfile change change
[ https://issues.apache.org/jira/browse/ARTEMIS-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4005. - Resolution: Fixed > e2e-tests module is broken due Dockerfile change change > --- > > Key: ARTEMIS-4005 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4005 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.26.0 >Reporter: Tiago Bueno >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The e2e-tests module is failing to get executed due 2 problem: > * The centos dockerfile name has changed > * Some classes were moved to artemis-unit-test-support module -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4005) e2e-tests module is broken due Dockerfile change change
[ https://issues.apache.org/jira/browse/ARTEMIS-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-4005: --- Fix Version/s: 2.26.0 Affects Version/s: 2.26.0 (was: 3.0.0) Assignee: Robbie Gemmell > e2e-tests module is broken due Dockerfile change change > --- > > Key: ARTEMIS-4005 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4005 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.26.0 >Reporter: Tiago Bueno >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.26.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The e2e-tests module is failing to get executed due 2 problem: > * The centos dockerfile name has changed > * Some classes were moved to artemis-unit-test-support module -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4002) Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in artemis script
[ https://issues.apache.org/jira/browse/ARTEMIS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607041#comment-17607041 ] Robbie Gemmell edited comment on ARTEMIS-4002 at 9/20/22 11:56 AM: --- The hidden ARTEMIS_LOGGING_CONF variable has been removed entirely on the new-logging branch already. was (Author: gemmellr): The ARTEMIS_LOGGING_CONF variable has been removed entirely on the new-logging branch already. > Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in > artemis script > --- > > Key: ARTEMIS-4002 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4002 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.25.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Trivial > Fix For: 3.0.0 > > > We set the logging system property using an env var, however we don't allow > that env var to be provided, it is currently overwritten > When the env can be easily modified, it would be great to be able to easily > provide an alternative logging file via setting the $ARTEMIS_LOGGING_CONF > variable. > We just have to set it only when it is empty! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4002) Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in artemis script
[ https://issues.apache.org/jira/browse/ARTEMIS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607125#comment-17607125 ] Robbie Gemmell commented on ARTEMIS-4002: - Yes, you would need to use the logging impls configuration props to provide your own file, rather than using the default auto-discovered config provided in the instance etc directory. Though you would obviously still need to know the impl-specific logging framework in use in order to provide it any applicable configuration via such a new (visible/configurable) environment variable, so the latter is hardly impl-agnostic even if you then dont need to know the well-known sysprop for setting its config file. Right now the scripts on the new-logging branch have no knowledge of the logging anymore, removing all the mechanics and simplifying them versus what what was there before (which has needed patched multiple times for upgraders, even in a bugfix release once). If they were to expose a new configurable env variable they would need to go back to having knowledge of the logging impl and if/when to use a provided config to set the config sysprop (which it doesnt by default due to using auto-discovery and leaving others free to specify it if they want). > Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in > artemis script > --- > > Key: ARTEMIS-4002 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4002 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.25.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Trivial > Fix For: 3.0.0 > > > We set the logging system property using an env var, however we don't allow > that env var to be provided, it is currently overwritten > When the env can be easily modified, it would be great to be able to easily > provide an alternative logging file via setting the $ARTEMIS_LOGGING_CONF > variable. > We just have to set it only when it is empty! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4002) Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in artemis script
[ https://issues.apache.org/jira/browse/ARTEMIS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607041#comment-17607041 ] Robbie Gemmell commented on ARTEMIS-4002: - The ARTEMIS_LOGGING_CONF variable has been removed entirely on logging branch already. > Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in > artemis script > --- > > Key: ARTEMIS-4002 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4002 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.25.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Trivial > Fix For: 3.0.0 > > > We set the logging system property using an env var, however we don't allow > that env var to be provided, it is currently overwritten > When the env can be easily modified, it would be great to be able to easily > provide an alternative logging file via setting the $ARTEMIS_LOGGING_CONF > variable. > We just have to set it only when it is empty! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4002) Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in artemis script
[ https://issues.apache.org/jira/browse/ARTEMIS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607041#comment-17607041 ] Robbie Gemmell edited comment on ARTEMIS-4002 at 9/20/22 9:29 AM: -- The ARTEMIS_LOGGING_CONF variable has been removed entirely on the new-logging branch already. was (Author: gemmellr): The ARTEMIS_LOGGING_CONF variable has been removed entirely on logging branch already. > Allow $ARTEMIS_LOGGING_CONF override by respecting pre-existing value in > artemis script > --- > > Key: ARTEMIS-4002 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4002 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.25.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Trivial > Fix For: 3.0.0 > > > We set the logging system property using an env var, however we don't allow > that env var to be provided, it is currently overwritten > When the env can be easily modified, it would be great to be able to easily > provide an alternative logging file via setting the $ARTEMIS_LOGGING_CONF > variable. > We just have to set it only when it is empty! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3997) update vertx-proton test dep to 4.3.3
[ https://issues.apache.org/jira/browse/ARTEMIS-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3997. - Resolution: Fixed > update vertx-proton test dep to 4.3.3 > - > > Key: ARTEMIS-3997 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3997 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: AMQP >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 3.0.0 > > > update vertx-proton test dep to 4.3.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3996) update to proton-j 0.34.0
[ https://issues.apache.org/jira/browse/ARTEMIS-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3996. - Resolution: Fixed > update to proton-j 0.34.0 > - > > Key: ARTEMIS-3996 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3996 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: AMQP >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 3.0.0 > > > update to proton-j 0.34.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3997) update vertx-proton test dep to 4.3.3
Robbie Gemmell created ARTEMIS-3997: --- Summary: update vertx-proton test dep to 4.3.3 Key: ARTEMIS-3997 URL: https://issues.apache.org/jira/browse/ARTEMIS-3997 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: AMQP Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 3.0.0 update vertx-proton test dep to 4.3.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3996) update to proton-j 0.34.0
Robbie Gemmell created ARTEMIS-3996: --- Summary: update to proton-j 0.34.0 Key: ARTEMIS-3996 URL: https://issues.apache.org/jira/browse/ARTEMIS-3996 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: AMQP Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 3.0.0 update to proton-j 0.34.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3985) update to activemq 5.17.2
[ https://issues.apache.org/jira/browse/ARTEMIS-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3985. - Resolution: Fixed > update to activemq 5.17.2 > - > > Key: ARTEMIS-3985 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3985 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: OpenWire >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > > update to activemq 5.17.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3985) update to activemq 5.17.2
Robbie Gemmell created ARTEMIS-3985: --- Summary: update to activemq 5.17.2 Key: ARTEMIS-3985 URL: https://issues.apache.org/jira/browse/ARTEMIS-3985 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: OpenWire Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.26.0 update to activemq 5.17.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3966) update build and instructions to simplify and clarify required steps
[
https://issues.apache.org/jira/browse/ARTEMIS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3966.
-
Resolution: Fixed
> update build and instructions to simplify and clarify required steps
>
>
> Key: ARTEMIS-3966
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3966
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: ActiveMQ-Artemis-Native
> Environment: quay.io/fedora/fedora:31-x86_64 docker image
>Reporter: Jiri Daněk
>Assignee: Clebert Suconic
>Priority: Major
>
> {noformat}
> + git clone https://github.com/apache/activemq-artemis-native.git
> Cloning into 'activemq-artemis-native'...
> Coverity Build Capture (64-bit) version 2022.6.0 on Linux
> 5.6.13-100.fc30.x86_64 x86_64
> Internal version numbers: 9501b3bfc3 p-2022.6-push-41
> + pushd activemq-artemis-native
> + ./scripts/compile-native.sh
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /builds/messaging/coverity-static-analysis/activemq-artemis
> CMake Warning (dev) in CMakeLists.txt:
> No project() command is present. The top-level CMakeLists.txt file must
> contain a literal, direct call to the project() command. Add a line of
> code such as
> project(ProjectName)
> near the top of the file, but after cmake_minimum_required().
> CMake is pretending there is a "project(Project)" command on the first
> line.
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Java: /usr/bin/java (found version "1.8.0_272")
> -- Found JNI: /usr/lib/jvm/java/jre/lib/amd64/libjawt.so
> --
> JNI_INCLUDE_DIRS=/usr/lib/jvm/java/include;/usr/lib/jvm/java/include/linux;/usr/lib/jvm/java/include
> --
> JNI_LIBRARIES=/usr/lib/jvm/java/jre/lib/amd64/libjawt.so;/usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> -- Using cross-compilation
> -- Using the following libaio library for linking: /usr/lib64/libaio.so
> -- Setting up library as artemis-native-32 based on current architecture
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /usr/bin/cmake
> -S/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> -B/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/depend
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> cd
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> && /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c/CMakeFiles/artemis-native.dir/DependInfo.cmake
> --color=
> Scanning dependencies of target artemis-native
> make[2]: Leaving directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/build
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artem
[jira] [Updated] (ARTEMIS-3966) update build and instructions to simplify and clarify required steps
[
https://issues.apache.org/jira/browse/ARTEMIS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3966:
Issue Type: Task (was: Bug)
Summary: update build and instructions to simplify and clarify required
steps (was: libaio does not build using ./scripts/compile-native.sh)
> update build and instructions to simplify and clarify required steps
>
>
> Key: ARTEMIS-3966
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3966
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: ActiveMQ-Artemis-Native
> Environment: quay.io/fedora/fedora:31-x86_64 docker image
>Reporter: Jiri Daněk
>Assignee: Clebert Suconic
>Priority: Major
>
> {noformat}
> + git clone https://github.com/apache/activemq-artemis-native.git
> Cloning into 'activemq-artemis-native'...
> Coverity Build Capture (64-bit) version 2022.6.0 on Linux
> 5.6.13-100.fc30.x86_64 x86_64
> Internal version numbers: 9501b3bfc3 p-2022.6-push-41
> + pushd activemq-artemis-native
> + ./scripts/compile-native.sh
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /builds/messaging/coverity-static-analysis/activemq-artemis
> CMake Warning (dev) in CMakeLists.txt:
> No project() command is present. The top-level CMakeLists.txt file must
> contain a literal, direct call to the project() command. Add a line of
> code such as
> project(ProjectName)
> near the top of the file, but after cmake_minimum_required().
> CMake is pretending there is a "project(Project)" command on the first
> line.
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Java: /usr/bin/java (found version "1.8.0_272")
> -- Found JNI: /usr/lib/jvm/java/jre/lib/amd64/libjawt.so
> --
> JNI_INCLUDE_DIRS=/usr/lib/jvm/java/include;/usr/lib/jvm/java/include/linux;/usr/lib/jvm/java/include
> --
> JNI_LIBRARIES=/usr/lib/jvm/java/jre/lib/amd64/libjawt.so;/usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> -- Using cross-compilation
> -- Using the following libaio library for linking: /usr/lib64/libaio.so
> -- Setting up library as artemis-native-32 based on current architecture
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /usr/bin/cmake
> -S/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> -B/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/depend
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> cd
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> && /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c/CMakeFiles/artemis-native.dir/DependInfo.cmake
> --color=
> Scanning dependencies of target artemis-native
> make[2]: Leaving directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
[jira] [Commented] (ARTEMIS-3966) libaio does not build using ./scripts/compile-native.sh
[
https://issues.apache.org/jira/browse/ARTEMIS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602197#comment-17602197
]
Robbie Gemmell commented on ARTEMIS-3966:
-
Seems nice, I have simplified the readme to reflect the new behaviour again.
I'm going to resolve this without a fix-version, just to avoid having an
artemis-native release version sitting around in the list for ages without any
real expectation of an imminent release. I'll add the JIRA to the version
created whenever there are actual aims to release it again.
> libaio does not build using ./scripts/compile-native.sh
> ---
>
> Key: ARTEMIS-3966
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3966
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native
> Environment: quay.io/fedora/fedora:31-x86_64 docker image
>Reporter: Jiri Daněk
>Assignee: Clebert Suconic
>Priority: Major
>
> {noformat}
> + git clone https://github.com/apache/activemq-artemis-native.git
> Cloning into 'activemq-artemis-native'...
> Coverity Build Capture (64-bit) version 2022.6.0 on Linux
> 5.6.13-100.fc30.x86_64 x86_64
> Internal version numbers: 9501b3bfc3 p-2022.6-push-41
> + pushd activemq-artemis-native
> + ./scripts/compile-native.sh
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /builds/messaging/coverity-static-analysis/activemq-artemis
> CMake Warning (dev) in CMakeLists.txt:
> No project() command is present. The top-level CMakeLists.txt file must
> contain a literal, direct call to the project() command. Add a line of
> code such as
> project(ProjectName)
> near the top of the file, but after cmake_minimum_required().
> CMake is pretending there is a "project(Project)" command on the first
> line.
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Java: /usr/bin/java (found version "1.8.0_272")
> -- Found JNI: /usr/lib/jvm/java/jre/lib/amd64/libjawt.so
> --
> JNI_INCLUDE_DIRS=/usr/lib/jvm/java/include;/usr/lib/jvm/java/include/linux;/usr/lib/jvm/java/include
> --
> JNI_LIBRARIES=/usr/lib/jvm/java/jre/lib/amd64/libjawt.so;/usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> -- Using cross-compilation
> -- Using the following libaio library for linking: /usr/lib64/libaio.so
> -- Setting up library as artemis-native-32 based on current architecture
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /usr/bin/cmake
> -S/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> -B/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/depend
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> cd
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> && /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c/CMakeFiles/artemis-native.dir/DependInfo.cmake
> --color=
> Scanning dep
[jira] [Resolved] (ARTEMIS-3975) examples pom enables snapshot repo for release artifacts
[ https://issues.apache.org/jira/browse/ARTEMIS-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3975. - Resolution: Fixed > examples pom enables snapshot repo for release artifacts > > > Key: ARTEMIS-3975 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3975 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.25.0 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > > The examples pom adds the snapshot repo to allow snapshot builds for the > examples to work in isolation (e.g as found in the assembly). This definition > incorrectly leaves release artifacts enabled, meaning the examples build can > check the snapshots repo for artifacts it should not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-3975) examples pom enables snapshot repo for release artifacts
[ https://issues.apache.org/jira/browse/ARTEMIS-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-3975: --- Assignee: Robbie Gemmell > examples pom enables snapshot repo for release artifacts > > > Key: ARTEMIS-3975 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3975 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.25.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > > The examples pom adds the snapshot repo to allow snapshot builds for the > examples to work in isolation (e.g as found in the assembly). This definition > incorrectly leaves release artifacts enabled, meaning the examples build can > check the snapshots repo for artifacts it should not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3975) examples pom enables snapshot repo for release artifacts
Robbie Gemmell created ARTEMIS-3975: --- Summary: examples pom enables snapshot repo for release artifacts Key: ARTEMIS-3975 URL: https://issues.apache.org/jira/browse/ARTEMIS-3975 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.25.0 Reporter: Robbie Gemmell Fix For: 2.26.0 The examples pom adds the snapshot repo to allow snapshot builds for the examples to work in isolation (e.g as found in the assembly). This definition incorrectly leaves release artifacts enabled, meaning the examples build can check the snapshots repo for artifacts it should not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3966) libaio does not build using ./scripts/compile-native.sh
[
https://issues.apache.org/jira/browse/ARTEMIS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601751#comment-17601751
]
Robbie Gemmell commented on ARTEMIS-3966:
-
https://github.com/apache/activemq-artemis-native/commit/ae502c94ecfc77ba3e744d45657a694a0407b2f0
{noformat}
commit ae502c94ecfc77ba3e744d45657a694a0407b2f0
Author: Robbie Gemmell
Date: Thu Sep 8 11:33:24 2022 +0100
ARTEMIS-3966: update README to reflect changes made previously to header
generation
{noformat}
> libaio does not build using ./scripts/compile-native.sh
> ---
>
> Key: ARTEMIS-3966
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3966
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native
> Environment: quay.io/fedora/fedora:31-x86_64 docker image
>Reporter: Jiri Daněk
>Assignee: Clebert Suconic
>Priority: Major
>
> {noformat}
> + git clone https://github.com/apache/activemq-artemis-native.git
> Cloning into 'activemq-artemis-native'...
> Coverity Build Capture (64-bit) version 2022.6.0 on Linux
> 5.6.13-100.fc30.x86_64 x86_64
> Internal version numbers: 9501b3bfc3 p-2022.6-push-41
> + pushd activemq-artemis-native
> + ./scripts/compile-native.sh
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /builds/messaging/coverity-static-analysis/activemq-artemis
> CMake Warning (dev) in CMakeLists.txt:
> No project() command is present. The top-level CMakeLists.txt file must
> contain a literal, direct call to the project() command. Add a line of
> code such as
> project(ProjectName)
> near the top of the file, but after cmake_minimum_required().
> CMake is pretending there is a "project(Project)" command on the first
> line.
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Java: /usr/bin/java (found version "1.8.0_272")
> -- Found JNI: /usr/lib/jvm/java/jre/lib/amd64/libjawt.so
> --
> JNI_INCLUDE_DIRS=/usr/lib/jvm/java/include;/usr/lib/jvm/java/include/linux;/usr/lib/jvm/java/include
> --
> JNI_LIBRARIES=/usr/lib/jvm/java/jre/lib/amd64/libjawt.so;/usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> -- Using cross-compilation
> -- Using the following libaio library for linking: /usr/lib64/libaio.so
> -- Setting up library as artemis-native-32 based on current architecture
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /usr/bin/cmake
> -S/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> -B/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/depend
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> cd
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> && /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/src/main/c/CMakeFiles/artemis-native.dir/DependInfo.cmake
> --color=
> Scanning dependencies of target artemis-native
> make[2]: Le
[jira] [Commented] (ARTEMIS-3966) libaio does not build using ./scripts/compile-native.sh
[
https://issues.apache.org/jira/browse/ARTEMIS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601750#comment-17601750
]
Robbie Gemmell commented on ARTEMIS-3966:
-
The readme needs updated at least, it doesnt seem to mention you need to
generate the file separately from running the scripts like
./scripts/compile-native.sh now (the .c file and .java do note it...which isnt
too useful if you havent known to look at them)
Could the cmake build not check the header file exists and fail-fast if not? Or
even just call maven itself to have the compiler generate the header, not too
dissimilar from before when cmake used to call javah and it generated the
header.
E.g in the first case it could at least do something like 'Check file exists ->
if not: fail and print "You need to run 'mvn generate-sources' first before
running ./scripts/compile-native.sh. Alternatively use mvn install -Pbare-metal
which does both."
> libaio does not build using ./scripts/compile-native.sh
> ---
>
> Key: ARTEMIS-3966
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3966
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native
> Environment: quay.io/fedora/fedora:31-x86_64 docker image
>Reporter: Jiri Daněk
>Assignee: Clebert Suconic
>Priority: Major
>
> {noformat}
> + git clone https://github.com/apache/activemq-artemis-native.git
> Cloning into 'activemq-artemis-native'...
> Coverity Build Capture (64-bit) version 2022.6.0 on Linux
> 5.6.13-100.fc30.x86_64 x86_64
> Internal version numbers: 9501b3bfc3 p-2022.6-push-41
> + pushd activemq-artemis-native
> + ./scripts/compile-native.sh
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /builds/messaging/coverity-static-analysis/activemq-artemis
> CMake Warning (dev) in CMakeLists.txt:
> No project() command is present. The top-level CMakeLists.txt file must
> contain a literal, direct call to the project() command. Add a line of
> code such as
> project(ProjectName)
> near the top of the file, but after cmake_minimum_required().
> CMake is pretending there is a "project(Project)" command on the first
> line.
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- The C compiler identification is GNU 9.3.1
> -- The CXX compiler identification is GNU 9.3.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc - works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ - works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Java: /usr/bin/java (found version "1.8.0_272")
> -- Found JNI: /usr/lib/jvm/java/jre/lib/amd64/libjawt.so
> --
> JNI_INCLUDE_DIRS=/usr/lib/jvm/java/include;/usr/lib/jvm/java/include/linux;/usr/lib/jvm/java/include
> --
> JNI_LIBRARIES=/usr/lib/jvm/java/jre/lib/amd64/libjawt.so;/usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> -- Using cross-compilation
> -- Using the following libaio library for linking: /usr/lib64/libaio.so
> -- Setting up library as artemis-native-32 based on current architecture
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> /usr/bin/cmake
> -S/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> -B/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> --check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> make -f src/main/c/CMakeFiles/artemis-native.dir/build.make
> src/main/c/CMakeFiles/artemis-native.dir/depend
> make[2]: Entering directory
> '/builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native'
> cd
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
> && /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /builds/messaging/coverity-static-analysis/activemq-artemis/activemq-artemis-native
>
> /builds/messaging/coverity-static-analysis/activemq-artemis/a
[jira] [Created] (AMQ-9074) remove various .js dependencies and source listing from javadoc output
Robbie Gemmell created AMQ-9074: --- Summary: remove various .js dependencies and source listing from javadoc output Key: AMQ-9074 URL: https://issues.apache.org/jira/browse/AMQ-9074 Project: ActiveMQ Issue Type: Task Components: Documentation Affects Versions: 5.17.2 Reporter: Robbie Gemmell Fix For: 5.18.0 Following https://openjdk.org/jeps/225), the javadoc output on JDK9+ has included a search box. To enable this various javascript files and a zipped index are included in the javadoc output. This means they were introduced to the javadoc output once the project required Java 11, i.e from 5.17.0, as previously Java 8 was used to run the release builds. These files are of whatever version the JDK used to run the build has included, and can tend to get stale (as per ARTEMIS-3971) Setting the -noindex option when building the javadoc removes the search, so we can add this option and remove the need to deal with these files going stale in future. Many of the javadoc build configs currently configure inclusion of an HTML source listing, which results in a fairly huge (>200MB) and yet often redundant output. Complete sources are easily available via github etc, and the sources and javadocs are also published to Maven Central where IDEs will grab them, which is likely how/where many people will look at sources+javadocs these days. There seems to be little need to burn the time and space including a HTML source listing, so this also looks to disable that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3971) remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3971.
-
Resolution: Fixed
> remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.20.0, 2.21.0, 2.22.0, 2.23.0, 2.23.1, 2.24.0, 2.25.0
>Reporter: Jakub Moravec
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.26.0
>
>
> Following [https://openjdk.org/jeps/225]), the javadoc output on JDK9+ has
> included a search box. To enable this various javascript files and a zipped
> index are included in the javadoc output. This means they were introduced to
> the once the project required Java 11, i.e from 2.20.0, as previously Java 8
> was used to run the release builds. These files are of whatever version the
> JDK used to run the build has included, and can tend to get stale.
> Setting the -noindex option when building the javadoc removes the search, so
> we can add this option and remove the need to deal with these files doing
> stale in future.
>
>
> \# Original report
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> {_}{{_}}proto{{_}}{_} property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g {_}{{_}}proto{{_}}{_},
> toString, etc) results in a returned object with a modified prototype
> instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3971) remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3971:
Description:
Following [https://openjdk.org/jeps/225]), the javadoc output on JDK9+ has
included a search box. To enable this various javascript files and a zipped
index are included in the javadoc output. This means they were introduced to
the once the project required Java 11, i.e from 2.20.0, as previously Java 8
was used to run the release builds. These files are of whatever version the JDK
used to run the build has included, and can tend to get stale.
Setting the -noindex option when building the javadoc removes the search, so we
can add this option and remove the need to deal with these files doing stale in
future.
\# Original report
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
{_}{{_}}proto{{_}}{_} property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even after
sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
.append(), and others) may execute untrusted code. This problem is patched in
jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
{quote}jQuery UI is a curated set of user interface interactions, effects,
widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
potentially vulnerable to cross-site scripting. Initializing a checkboxradio
widget on an input enclosed within a label makes that parent label contents
considered as the input label. Calling `.checkboxradio( "refresh" )` on such a
widget and the initial HTML contained encoded HTML entities will make them
erroneously get decoded. This can lead to potentially executing JavaScript
code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
someone who can change the initial HTML can wrap all the non-input contents of
the `label` in a `span`.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
{quote}This affects the package jszip before 3.7.0. Crafting a new zip file
with filenames set to Object prototype values (e.g {_}{{_}}proto{{_}}{_},
toString, etc) results in a returned object with a modified prototype instance.
{quote}
was:
Following [https://openjdk.org/jeps/225]), the javadoc output on JDK9+ has
included a search box. To enable this various javascript files and a zipped
index are included in the javadoc output. This means they were introduced to
the once the project required Java 11, i.e from 2.20.0, as previously Java 8
was used to run the release builds. These files are of whatever version the JDK
used to run the build has included, and can tend to get stale.
Setting the -noindex option when building the javadoc removes the search, so we
can add this option and remove the need to deal with these files doing stale in
future.
# Original report
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
{_}{{_}}proto{{_}}{_} property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even af
[jira] [Updated] (ARTEMIS-3971) remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3971:
Description:
Following [https://openjdk.org/jeps/225]), the javadoc output on JDK9+ has
included a search box. To enable this various javascript files and a zipped
index are included in the javadoc output. This means they were introduced to
the once the project required Java 11, i.e from 2.20.0, as previously Java 8
was used to run the release builds. These files are of whatever version the JDK
used to run the build has included, and can tend to get stale.
Setting the -noindex option when building the javadoc removes the search, so we
can add this option and remove the need to deal with these files doing stale in
future.
# Original report
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
{_}{{_}}proto{{_}}{_} property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even after
sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
.append(), and others) may execute untrusted code. This problem is patched in
jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
{quote}jQuery UI is a curated set of user interface interactions, effects,
widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
potentially vulnerable to cross-site scripting. Initializing a checkboxradio
widget on an input enclosed within a label makes that parent label contents
considered as the input label. Calling `.checkboxradio( "refresh" )` on such a
widget and the initial HTML contained encoded HTML entities will make them
erroneously get decoded. This can lead to potentially executing JavaScript
code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
someone who can change the initial HTML can wrap all the non-input contents of
the `label` in a `span`.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
{quote}This affects the package jszip before 3.7.0. Crafting a new zip file
with filenames set to Object prototype values (e.g {_}{{_}}proto{{_}}{_},
toString, etc) results in a returned object with a modified prototype instance.
{quote}
was:
Following https://openjdk.org/jeps/225), the javadoc output on JDK9+ has
included a search box. To enable this various javascript files and a zipped
index are included in the javadoc output. This means they were introduced to
the once the project required Java 11, i.e from 2.20.0, as previously Java 8
was used to run the release builds. These files are of whatever version the JDK
used to run the build has included, and can tend to get stale.
Setting the -noindex option when building the javadoc removes the search, so we
can add this option and remove the need to deal with these files doing stale in
future.
Original report =
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
_{_}proto{_}_ property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even after
[jira] [Assigned] (ARTEMIS-3971) remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned ARTEMIS-3971:
---
Fix Version/s: 2.26.0
Affects Version/s: 2.25.0
2.23.1
2.23.0
2.22.0
2.21.0
2.20.0
Assignee: Robbie Gemmell
Description:
Following https://openjdk.org/jeps/225), the javadoc output on JDK9+ has
included a search box. To enable this various javascript files and a zipped
index are included in the javadoc output. This means they were introduced to
the once the project required Java 11, i.e from 2.20.0, as previously Java 8
was used to run the release builds. These files are of whatever version the JDK
used to run the build has included, and can tend to get stale.
Setting the -noindex option when building the javadoc removes the search, so we
can add this option and remove the need to deal with these files doing stale in
future.
Original report =
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
_{_}proto{_}_ property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even after
sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
.append(), and others) may execute untrusted code. This problem is patched in
jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
{quote}jQuery UI is a curated set of user interface interactions, effects,
widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
potentially vulnerable to cross-site scripting. Initializing a checkboxradio
widget on an input enclosed within a label makes that parent label contents
considered as the input label. Calling `.checkboxradio( "refresh" )` on such a
widget and the initial HTML contained encoded HTML entities will make them
erroneously get decoded. This can lead to potentially executing JavaScript
code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
someone who can change the initial HTML can wrap all the non-input contents of
the `label` in a `span`.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
{quote}This affects the package jszip before 3.7.0. Crafting a new zip file
with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
etc) results in a returned object with a modified prototype instance.
{quote}
was:
Please upgrade the listed libraries, as there are reported vulnerabilities for
them, see the list below. This is a blocker for production deployments.
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
{quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
pollution. If an unsanitized source object contained an enumerable
_{_}proto{_}_ property, it could extend the native Object.prototype.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
{quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
passing HTML from untrusted sources - even after sanitizing it - to one of
jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
execute untrusted code. This problem is patched in jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
{quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
passing HTML containing elements from untrusted sources - even after
sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
.append(), and others) may execute untrusted code. This problem is patched in
jQuery 3.5.0.
{quote}
[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
{quote}jQuery UI is a curated set of user interface interactions, effects,
widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
potentiall
[jira] [Updated] (ARTEMIS-3971) remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3971:
Summary: remove vulnerable .js deps from javadoc output - jQuery, jQuery
UI, jszip (was: Upgrade vulnerable javascript dependencies - jQuery, jQuery
UI, jszip)
> remove vulnerable .js deps from javadoc output - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3971) Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600879#comment-17600879
]
Robbie Gemmell commented on ARTEMIS-3971:
-
Ill be removing the jquery etc bits shortly with -noindex on the javadoc build.
We can discuss seperately removing the javadoc as a whole.
> Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-3971) Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600776#comment-17600776
]
Robbie Gemmell edited comment on ARTEMIS-3971 at 9/6/22 1:54 PM:
-
Not the whole web folder unless you want to remove the entire console etc since
there are war files in the root. Though you can actually do that too by
modifying the etc/bootstrap.xml file I believe.
The web dir splits most of the individual bits served from it into subdirs
though, should be fairly easy to align with the content by looking at it and
perhaps the URLs...e.g manual, api (javadoc), examples as you mentioned.
I havent tried it but as justin said the broker itself doesnt really depend on
those bits being there, so you should be able to remove as much or little as
you like, with it just 404ing if someone tries to use a bit you remove (you
could update the index accordingly to avoid that also).
EDIT: ninja'd...what Justin said, lol.
was (Author: gemmellr):
Not the whole web folder unless you want to remove the entire console etc since
there are war files in the root. Though you can actually do that too by
modifying the etc/bootstrap.xml file I believe.
The web dir splits most of the individual bits served from it into subdirs
though, should be fairly easy to align with the content by looking at it and
perhaps the URLs...e.g manual, api (javadoc), examples as you mentioned.
EDIT: ninja'd...what Justin said, lol.
I havent tried it but as justin said the broker itself doesnt really depend on
those bits being there, so you should be able to remove as much or little as
you like, with it just 404ing if someone tries to use a bit you remove (you
could update the index accordingly to avoid that also).
> Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-3971) Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600776#comment-17600776
]
Robbie Gemmell edited comment on ARTEMIS-3971 at 9/6/22 1:54 PM:
-
Not the whole web folder unless you want to remove the entire console etc since
there are war files in the root. Though you can actually do that too by
modifying the etc/bootstrap.xml file I believe.
The web dir splits most of the individual bits served from it into subdirs
though, should be fairly easy to align with the content by looking at it and
perhaps the URLs...e.g manual, api (javadoc), examples as you mentioned.
EDIT: ninja'd...what Justin said, lol.
I havent tried it but as justin said the broker itself doesnt really depend on
those bits being there, so you should be able to remove as much or little as
you like, with it just 404ing if someone tries to use a bit you remove (you
could update the index accordingly to avoid that also).
was (Author: gemmellr):
Not the whole web folder unless you want to remove the entire console etc since
there are war files in the root. Though you can actually do that too by
modifying the etc/bootstrap.xml file I believe.
The web dir splits most of the individual bits served from it into subdirs
though, should be fairly easy to align with the content by looking at it and
perhaps the URLs...e.g manual, api (javadoc), examples as you mentioned.
I havent tried it but as justin said the broker itself doesnt really depend on
those bits being there, so you should be able to remove as much or little as
you like, with it just 404ing if someone tries to use a bit you remove (you
could update the index accordingly to avoid that also).
> Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3971) Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600776#comment-17600776
]
Robbie Gemmell commented on ARTEMIS-3971:
-
Not the whole web folder unless you want to remove the entire console etc since
there are war files in the root. Though you can actually do that too by
modifying the etc/bootstrap.xml file I believe.
The web dir splits most of the individual bits served from it into subdirs
though, should be fairly easy to align with the content by looking at it and
perhaps the URLs...e.g manual, api (javadoc), examples as you mentioned.
I havent tried it but as justin said the broker itself doesnt really depend on
those bits being there, so you should be able to remove as much or little as
you like, with it just 404ing if someone tries to use a bit you remove (you
could update the index accordingly to avoid that also).
> Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3971) Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
[
https://issues.apache.org/jira/browse/ARTEMIS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600735#comment-17600735
]
Robbie Gemmell commented on ARTEMIS-3971:
-
These are part of the javadoc output on newer JDKs (following
https://openjdk.org/jeps/225), so to justins earlier comment you can simply
remove it for now.
The actual javadoc content is down to the specific JDK used to build the
output, and these have all it seems been upgraded in the JDK previously or will
be soon (e.g updated but not released yet), e.g:
https://bugs.openjdk.org/browse/JDK-8289454
https://bugs.openjdk.org/browse/JDK-8291029
https://bugs.openjdk.org/browse/JDK-8272180
It seems you can perhaps also disable the search feature and that prevents all
of their inclusions, by disabling the index. Since the search box causing the
issue was never there before ( Upgrade vulnerable javascript dependencies - jQuery, jQuery UI, jszip
> -
>
> Key: ARTEMIS-3971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.24.0
>Reporter: Jakub Moravec
>Priority: Critical
>
> Please upgrade the listed libraries, as there are reported vulnerabilities
> for them, see the list below. This is a blocker for production deployments.
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11358]
> {quote}jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other
> products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype
> pollution. If an unsanitized source object contained an enumerable
> _{_}proto{_}_ property, it could extend the native Object.prototype.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11022]
> {quote}In jQuery versions greater than or equal to 1.2 and before 3.5.0,
> passing HTML from untrusted sources - even after sanitizing it - to one of
> jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may
> execute untrusted code. This problem is patched in jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11023]
> {quote}In jQuery versions greater than or equal to 1.0.3 and before 3.5.0,
> passing HTML containing elements from untrusted sources - even after
> sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(),
> .append(), and others) may execute untrusted code. This problem is patched in
> jQuery 3.5.0.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-31160]
> {quote}jQuery UI is a curated set of user interface interactions, effects,
> widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are
> potentially vulnerable to cross-site scripting. Initializing a checkboxradio
> widget on an input enclosed within a label makes that parent label contents
> considered as the input label. Calling `.checkboxradio( "refresh" )` on such
> a widget and the initial HTML contained encoded HTML entities will make them
> erroneously get decoded. This can lead to potentially executing JavaScript
> code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue,
> someone who can change the initial HTML can wrap all the non-input contents
> of the `label` in a `span`.
> {quote}
> [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-23413]
> {quote}This affects the package jszip before 3.7.0. Crafting a new zip file
> with filenames set to Object prototype values (e.g _{_}proto{_}_, toString,
> etc) results in a returned object with a modified prototype instance.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3970) update keycloak used in example to 19.0.1
[ https://issues.apache.org/jira/browse/ARTEMIS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3970. - Assignee: Robbie Gemmell Resolution: Fixed > update keycloak used in example to 19.0.1 > - > > Key: ARTEMIS-3970 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3970 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3970) update keycloak used in example to 19.0.1
[ https://issues.apache.org/jira/browse/ARTEMIS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3970: Fix Version/s: 2.26.0 > update keycloak used in example to 19.0.1 > - > > Key: ARTEMIS-3970 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3970 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3970) update keycloak used in example to 19.0.1
Robbie Gemmell created ARTEMIS-3970: --- Summary: update keycloak used in example to 19.0.1 Key: ARTEMIS-3970 URL: https://issues.apache.org/jira/browse/ARTEMIS-3970 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (AMQNET-795) Bệnh táo bón là gì?
[ https://issues.apache.org/jira/browse/AMQNET-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell deleted AMQNET-795: -- > Bệnh táo bón là gì? > --- > > Key: AMQNET-795 > URL: https://issues.apache.org/jira/browse/AMQNET-795 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: conmeohienlam92 >Priority: Major > > Đường tiêu hóa ở người bao gồm rất nhiều cơ quan, bắt đầu từ cơ quan miệng là > nơi tiếp nhận thức ăn đến điểm cuối là hậu môn nơi thải các chất không tiêu > hóa được ra ngoài. > Cơ quan này có nhiệm vụ phân hủy thức ăn thành các chất dinh dưỡng có thể hấp > thụ được vào cơ thể, cung cấp năng lượng cho cơ thể hoạt động. > Táo bón là một trong những bệnh lý phổ biến về đường tiêu hóa thường gặp và > rất phổ biến hiện nay. Những bệnh liên quan đến hệ tiêu hóa không chỉ gây cảm > giác khó chịu mà còn ảnh hưởng tới cuộc sống, công việc của người bệnh. > !https://sulforaphane-lab.vn/wp-content/uploads/2022/07/nguyen-nhan-dau-hieu-va-phuong-phap-dieu-tri-tao-bon-so-1.jpg! > #benh_tao_bon #benh_tao_bon_la_gi > Xem thêm: [Táo bón: Nguyên nhân, dấu hiệu và phương pháp điều > trị|https://sulforaphane-lab.vn/tao-bon/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (AMQ-9071) Custom Tees
[ https://issues.apache.org/jira/browse/AMQ-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell deleted AMQ-9071: > Custom Tees > --- > > Key: AMQ-9071 > URL: https://issues.apache.org/jira/browse/AMQ-9071 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Dustin Figueroa >Priority: Major > > [Custom Tees|https://teesly.com] > Teesly is a lifestyle brand for stock apparel designs and custom apparel > printing of tees, t-shirts, custom tees, custom printed t-shirts along with > embroidery. > #To know about more visit our website: https://teesly.com -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (AMQ-9072) Bệnh táo bón là gì?
[ https://issues.apache.org/jira/browse/AMQ-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell deleted AMQ-9072: > Bệnh táo bón là gì? > --- > > Key: AMQ-9072 > URL: https://issues.apache.org/jira/browse/AMQ-9072 > Project: ActiveMQ > Issue Type: Bug >Reporter: chieunaychanqua92 >Priority: Major > > Đường tiêu hóa ở người bao gồm rất nhiều cơ quan, bắt đầu từ cơ quan miệng là > nơi tiếp nhận thức ăn đến điểm cuối là hậu môn nơi thải các chất không tiêu > hóa được ra ngoài. > Cơ quan này có nhiệm vụ phân hủy thức ăn thành các chất dinh dưỡng có thể hấp > thụ được vào cơ thể, cung cấp năng lượng cho cơ thể hoạt động. > Táo bón là một trong những bệnh lý phổ biến về đường tiêu hóa thường gặp và > rất phổ biến hiện nay. Những bệnh liên quan đến hệ tiêu hóa không chỉ gây cảm > giác khó chịu mà còn ảnh hưởng tới cuộc sống, công việc của người bệnh. > !https://sulforaphane-lab.vn/wp-content/uploads/2022/07/nguyen-nhan-dau-hieu-va-phuong-phap-dieu-tri-tao-bon-so-1.jpg! > #benh_tao_bon #benh_tao_bon_la_gi > Xem thêm: [Táo bón: Nguyên nhân, dấu hiệu và phương pháp điều > trị|https://sulforaphane-lab.vn/tao-bon/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9065) Replace ianal-maven-plugin with geronimo tools-maven-plugin
[ https://issues.apache.org/jira/browse/AMQ-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599010#comment-17599010 ] Robbie Gemmell commented on AMQ-9065: - re: fix-version, seems like the 5.17.x branch still needs updated. > Replace ianal-maven-plugin with geronimo tools-maven-plugin > --- > > Key: AMQ-9065 > URL: https://issues.apache.org/jira/browse/AMQ-9065 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Fix For: 5.18.0, 5.17.3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > To support JDK 17 compile time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (AMQ-9069) Trang Chủ - AAA JEANS - Quần Jean Nữ Đẹp
[ https://issues.apache.org/jira/browse/AMQ-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell deleted AMQ-9069: > Trang Chủ - AAA JEANS - Quần Jean Nữ Đẹp > > > Key: AMQ-9069 > URL: https://issues.apache.org/jira/browse/AMQ-9069 > Project: ActiveMQ > Issue Type: Bug >Reporter: AaaJeans >Priority: Major > > aaajeans.com - Aaa Jeans là thương hiệu quần jean nữ đầu tiên tại Việt Nam > với các thiết kế đặc biệt phù hợp cho vóc dáng phụ nữ Việt. > Chi tiết liên hệ tại : > Website : [https://aaajeans.com/] > Twitter : [https://twitter.com/AaaJeans] > Flickr : [https://flickr.com/people/aaajeans/] > Gab : [https://gab.com/aaajeansvn] > Netboad : [https://aaajeans.netboard.me/] > Folkd : [https://folkd.com/user/aaajeansvn] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3949.
---
Resolution: Information Provided
I have added some more detail to the javadoc via ARTEMIS-3954 around the
session+children thread model and the related effect of setting a handle.
Closing this one following the previous comments around it being as
intended/expected.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{ClientProducerImpl#doSend}} method and in the
> {{ClientSessionImpl#acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> # From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the {{doSend}} method does not even belong
> to the session.
> # The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}'s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the {{ClientMessage}} belongs to. Thus, it would require user code to
> e.g. implement their own message store just to be able to synchronize the
> right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl{}}}, {{{}ClientMessageImpl{}}}, and similar have full
> access and knowledge about their synchronization needs. I thus suggest to
> implement synchronization where needed instead of leaving the user alone with
> this issue, where the solution actually means to reimplement a lot of
> functionality of the client.
> e.g.
> {code:java}
> startCall();
> try {
>sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> } finally {
>endCall();
> }{code}
>
> could be replaced with something like
> {code:java}
> synchronized(this) {
>sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> }{code}
>
> *EDIT:*
> Clicking through the client code, I realized that there actually is
> synchronization on the send method in {{{}ChannelImpl{}}}:
> {code:java}
>// This must never called by more than one thread concurrently
>private boolean send(final Packet packet, final int reconnectID, final
> boolean flush, final boolean batch) {
> if (invokeInterceptors(packet, interceptors, connection) != null) {
> return false;
> }
> synchronized (sendLock) {
> ...
> }
> }
> {code}
> Even though, the comment explicitly says not to call this message
> concurrently, there is a synchronization block enclosing all the logic of the
> function.
> Might the comment be deprecated and the concurrency warning thus too? Do I
> miss something?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3954) add some detail to core-client thread model javadoc note
[ https://issues.apache.org/jira/browse/ARTEMIS-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3954. - Fix Version/s: 2.25.0 Assignee: Robbie Gemmell Resolution: Fixed > add some detail to core-client thread model javadoc note > > > Key: ARTEMIS-3954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3954 > Project: ActiveMQ Artemis > Issue Type: Task > Components: API >Affects Versions: 2.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.25.0 > > > Add some more detail to the core-client thread model Javadoc note, > elaborating that its session etc are single threaded, i.e the model is > basically the same as that of the JMS client it underpins. Follows discussion > on ARTEMIS-3949. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3954) add some detail to core-client thread model javadoc note
Robbie Gemmell created ARTEMIS-3954: --- Summary: add some detail to core-client thread model javadoc note Key: ARTEMIS-3954 URL: https://issues.apache.org/jira/browse/ARTEMIS-3954 Project: ActiveMQ Artemis Issue Type: Task Components: API Affects Versions: 2.24.0 Reporter: Robbie Gemmell Add some more detail to the core-client thread model Javadoc note, elaborating that its session etc are single threaded, i.e the model is basically the same as that of the JMS client it underpins. Follows discussion on ARTEMIS-3949. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583534#comment-17583534
]
Robbie Gemmell commented on ARTEMIS-3949:
-
{quote}
But following your description, having asynchroneous handlers, some handlers
might fail and messages would still be acknowledged, if any message that
arrived later calls acknowledge.
Did I get that right?
{quote}
Close but not exactly. The call acknowledges the entire sessions delivered
messages, there is no ordering / sequence consideration at all. It isnt 'ack
messages arriving before this one', its 'all delivered messages'. Any call to
acknowledge will ack *all* messages delivered to that point, regardless of any
sequence of arrival or which you call the operation on. Again, as JMS mandates
CLIENT_ACK mode behaves.
Since you are meant to be using the handler [thread] itself to..handle..the
messages and indeed the session, this normally isnt so surprising since its
typical to handle and acknowledge messages in the order they arrive, and theres
only one handler thread delivering on the session. But if you are passing your
messages off from the handler, entirely against the expected thread model, and
processing them in other threads then clearly you cant just call acknowledge
(in violation of the thread model) without coordination since if you did you
would never _any_ idea what you were actually acknowledging. You should really
be coordinating things back to the handler to do the ack, e.g a blocking work
queue, or using multiple sessions+handlers so you dont need to coordinate (each
session having its own delivery thread), or not using the handler API at all
and coordinating worker threads while using the consumer.receive() APIs.
{quote}
Does the individualAcknowledge() method definitely only acknowledge this one
message or is there also something else to know?
{quote}
I've never used the Core client directly but given the methods existence, and
its use for implementing the 'individual ack' session mode extension in the JMS
client I would expect it does exactly what it says on the tin.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{ClientProducerImpl#doSend}} method and in the
> {{ClientSessionImpl#acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> # From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the {{doSend}} method does not even belong
> to the session.
> # The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}'s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the {{ClientMessage}} belongs to. Thus, it would require user code to
> e.g. implement their own message store just to be able to synchronize the
> right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl{}}}, {{{}ClientMessageImpl{}}}, and similar have full
> access and knowledge about their synchronization needs. I thus suggest to
> implement synchronization where needed instead of leaving the user alone with
> this issue, where the solution actually means to reimplement a lot of
> functionality of the client.
> e.g.
> {code:java}
> startCall();
> try {
>sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> } finally {
>endCall();
> }{code}
>
> could be replaced with something like
> {code:java}
> synchronized(this) {
>sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> }{code}
>
> *EDIT:*
> Clicking through the client code, I realized that there actually is
> synchronization on the send method in {{{}ChannelImpl{}}}:
> {code:java}
>// This must never called by more than one thread concurrently
>private boolean send(final Packet packet, final int reconnectID, final
> boolean flush, final boolean batch) {
> if (invokeInterceptors(packet, interceptors, connection) != null) {
> return false;
> }
> synchronized (sendLock) {
> ...
> }
> }
> {code}
> Even though, the comment explicitly says not to call this message
> concurrently, there is a synchronizat
[jira] [Assigned] (ARTEMIS-3950) dont prepare unused debug detail during xml data import processing
[ https://issues.apache.org/jira/browse/ARTEMIS-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-3950: --- Assignee: Robbie Gemmell > dont prepare unused debug detail during xml data import processing > -- > > Key: ARTEMIS-3950 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3950 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: 2.25.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The xml data import command for the cli prepares some details in a > StringBuilder for use in debug logging. Though it does avoid calling > toString() on the builder if the logger isnt enabled for debug output, it > would be better not to prepare the detail at all since it takes various steps > to do so including toString() of message metadata. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3950) dont prepare unused debug detail during xml data import processing
[ https://issues.apache.org/jira/browse/ARTEMIS-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3950. - Resolution: Fixed > dont prepare unused debug detail during xml data import processing > -- > > Key: ARTEMIS-3950 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3950 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.24.0 >Reporter: Robbie Gemmell >Priority: Trivial > Fix For: 2.25.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The xml data import command for the cli prepares some details in a > StringBuilder for use in debug logging. Though it does avoid calling > toString() on the builder if the logger isnt enabled for debug output, it > would be better not to prepare the detail at all since it takes various steps > to do so including toString() of message metadata. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3953) project compile failed on mac
[
https://issues.apache.org/jira/browse/ARTEMIS-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583427#comment-17583427
]
Robbie Gemmell commented on ARTEMIS-3953:
-
What was your JAVA_HOME set to, given thats what it was complaining about?
Setting the javadocExecutable value as you did does not seem appropriate since
it is platform-specific, and shouldnt be needed. As Justin said, there are also
other folks developing on Mac's that would make me expect this to work overall,
so I'd wonder if that points to something different about your particular env,
though it is interesting that updating maven resolved it.
> project compile failed on mac
> --
>
> Key: ARTEMIS-3953
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3953
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: gongping.zhu
>Priority: Major
>
> when i git clone zhe project and import the IDEA, it can not success use
> maven to compile;
>
> it need add zhe below element for each maven-javadoc-plugin configuation
> ${java.home}/bin/javadoc
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583094#comment-17583094
]
Robbie Gemmell commented on ARTEMIS-3949:
-
I'll leave this open for a bit in case anyone has views otherwise, but...this
is doing what is expected and intended currently, Clebert already said he
doesnt think we should change it, I agree with that view, and I expect Justin
does also given lack of comment when updating things earlier.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in
> the {{ClientSessionImpls}} {{acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> 1. From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the `doSend` method does not even belong to
> the session.
> 2. The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the `ClientMessage` belongs to.
> Thus, it would require user code to e.g. implement their own message store
> just to be able to synchronize the right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access
> and knowledge about their synchronization needs.
> I thus suggest to implement synchronization where needed instead of leaving
> the user alone with this issue, where the solution actually means to
> reimplement a lot of functionality of the client.
> E.g.
> {{startCall();}}
> {{try {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} finally {}}
> {{endCall();}}
>
> could be replaced with something like
> {{synchronized(this) {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583082#comment-17583082
]
Robbie Gemmell commented on ARTEMIS-3949:
-
Since a session is to be used single threaded, as mentioned before that means
that if you are using a consumer handler/listener callback the entire session
(and all its producers + consumers) also becomes dedicated to the
handler/listener callback thread of the session, which thus also becomes the
only thread allowed to acknowledge. That means you dont need to know the
session or the originally subscribing thread in your handler/listener since the
thread delivering the message to it is the only one allowed to acknowledge, or
do anything else on the session+children (except for close).
If you need concurrent processing of listeners you can use multiple sessions,
this giving them distinct delivery processing. Alternatively you could skip
handlers and create multiple sessions+recievers on their own threads and call
the consumer receive method(s) to get messages and later ack after processing
them. Or you could use a single thread to call receive on one/many consumers
and then dispatch details to other threads for processing, and then coordinate
return to the thread operating the session/consumers so it can acknowledge
messages. Yes, users need to understand the threading model.
Also, regardless of the approach you should be careful with acknowledge()
itself; it doesnt do what it seems you maybe think it does. The acknowledge()
method actually acks *all* previously delivered messages on a session, not just
the specific message it is called on (this bizareness is as per JMS Client
Acknowledge mode...though vendors often have specific extended ack modes for
individual-ack). It looks like the Core Message exposes an
individualAcknowledge() method that may be more akin to what you are after.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in
> the {{ClientSessionImpls}} {{acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> 1. From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the `doSend` method does not even belong to
> the session.
> 2. The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the `ClientMessage` belongs to.
> Thus, it would require user code to e.g. implement their own message store
> just to be able to synchronize the right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access
> and knowledge about their synchronization needs.
> I thus suggest to implement synchronization where needed instead of leaving
> the user alone with this issue, where the solution actually means to
> reimplement a lot of functionality of the client.
> E.g.
> {{startCall();}}
> {{try {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} finally {}}
> {{endCall();}}
>
> could be replaced with something like
> {{synchronized(this) {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-3950) dont prepare unused debug detail during xml data import processing
Robbie Gemmell created ARTEMIS-3950: --- Summary: dont prepare unused debug detail during xml data import processing Key: ARTEMIS-3950 URL: https://issues.apache.org/jira/browse/ARTEMIS-3950 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.24.0 Reporter: Robbie Gemmell Fix For: 2.25.0 The xml data import command for the cli prepares some details in a StringBuilder for use in debug logging. Though it does avoid calling toString() on the builder if the logger isnt enabled for debug output, it would be better not to prepare the detail at all since it takes various steps to do so including toString() of message metadata. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582960#comment-17582960
]
Robbie Gemmell commented on ARTEMIS-3949:
-
It clearly isnt meant to be in the sense that a) it is not, and b) it has a
simple mechanism around noting when it can tell you are misusing it, i.e its
not an accident or oversight but quite deliberate.
You might not use the [Core] JMS client but the Core client is an integral part
of it and it would seem decisions were made around sharing a similar
threading/thread-safety model between the two parts. Which is to say a session
and its objects are single threaded. Your reactive publishers may be thread
agnostic to users but that doesnt necessarily mean their implementation can be
if the thigns they are using are not.
You neednt guess where sychronisation is required. The entire scope of a
session and all its related objects is single threaded (except close methods,
which can be called concurrently). You dont need to synchronize on the session
at all, but you do need to ensure you use things in its scope from a single
thread, including message acknoweldgement for that session.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Assignee: Clebert Suconic
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in
> the {{ClientSessionImpls}} {{acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> 1. From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the `doSend` method does not even belong to
> the session.
> 2. The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the `ClientMessage` belongs to.
> Thus, it would require user code to e.g. implement their own message store
> just to be able to synchronize the right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access
> and knowledge about their synchronization needs.
> I thus suggest to implement synchronization where needed instead of leaving
> the user alone with this issue, where the solution actually means to
> reimplement a lot of functionality of the client.
> E.g.
> {{startCall();}}
> {{try {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} finally {}}
> {{endCall();}}
>
> could be replaced with something like
> {{synchronized(this) {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations
[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582915#comment-17582915
]
Robbie Gemmell commented on ARTEMIS-3949:
-
What you are asking for is for the session+children implementation to actually
be made safe for use from multiple threads, which it isnt currently and is
clearly not meant to be. What is in place with the counter is a form of
helper/warning system to potentially advise that you are using multiple threads
where you should not be doing so.
I would expect the current behaviour stems directly from or was influenced by
the explicit JMS threading model where a given Session and its child
producers/consumers are expressly single threaded (even such that using a
MessageListener on a MessageConsumer renders the parent Session to be dedicated
to the session-wide listener thread). Applications do have to know which thread
of theirs is using a Session and its related objects, including for
acknowledgement (which operates on the session). If you are handing messages
from one session out to multiple other threads for processing, you do need to
similarly coordinate things back the way for acknowledgement. Nothing is forced
to synchronise on the session object itself however vs using some external
means for coordination. There are other alternatives to doing any such thread
coordination like use of multiple sessions, of if lengthy parallel processing
isnt an issue perhaps just use of multiple listeners on a single session.
> Internally synchronize methods in ClientSession implementations
> ---
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.24.0
>Reporter: Peter Machon
>Assignee: Clebert Suconic
>Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in
> the {{ClientSessionImpls}} {{acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> 1. From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the `doSend` method does not even belong to
> the session.
> 2. The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the `ClientMessage` belongs to.
> Thus, it would require user code to e.g. implement their own message store
> just to be able to synchronize the right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access
> and knowledge about their synchronization needs.
> I thus suggest to implement synchronization where needed instead of leaving
> the user alone with this issue, where the solution actually means to
> reimplement a lot of functionality of the client.
> E.g.
> {{startCall();}}
> {{try {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} finally {}}
> {{endCall();}}
>
> could be replaced with something like
> {{synchronized(this) {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3946) Update to Netty 4.1.79
[ https://issues.apache.org/jira/browse/ARTEMIS-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3946. - Assignee: Robbie Gemmell Resolution: Fixed > Update to Netty 4.1.79 > -- > > Key: ARTEMIS-3946 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3946 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.25.0 > > > Update to Netty 4.1.79 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3946) Update to Netty 4.1.79
Robbie Gemmell created ARTEMIS-3946: --- Summary: Update to Netty 4.1.79 Key: ARTEMIS-3946 URL: https://issues.apache.org/jira/browse/ARTEMIS-3946 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Fix For: 2.25.0 Update to Netty 4.1.79 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3927) Update to PostgreSQL 42.4.1
[ https://issues.apache.org/jira/browse/ARTEMIS-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3927. - Resolution: Fixed > Update to PostgreSQL 42.4.1 > --- > > Key: ARTEMIS-3927 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3927 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Affects Versions: 2.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.25.0 > > > Update to PostgreSQL 42.4.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3927) Update to PostgreSQL 42.4.1
Robbie Gemmell created ARTEMIS-3927: --- Summary: Update to PostgreSQL 42.4.1 Key: ARTEMIS-3927 URL: https://issues.apache.org/jira/browse/ARTEMIS-3927 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Affects Versions: 2.24.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.25.0 Update to PostgreSQL 42.4.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
