[jira] [Commented] (AMQ-3686) Http Tunnel Servlet: Connection reset on the client

2021-06-20 Thread Diptesh Chakraborty (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366412#comment-17366412
 ] 

Diptesh Chakraborty commented on AMQ-3686:
--

Is this reproducible by any chance with latest version?

> Http Tunnel Servlet: Connection reset on the client
> ---
>
> Key: AMQ-3686
> URL: https://issues.apache.org/jira/browse/AMQ-3686
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.4.3, 5.5.0, 5.5.1
> Environment: Ubuntu 11.10
>Reporter: Thomas Pasch
>Priority: Major
>  Labels: http-tunneling, servlet
>
> We are using the tunnel servlet for a long time now in our application. There 
> were no problems with the 5.3.x versions of ActiveMQ. However, with newer 
> versions (5.5.0) we observe clients connection resets after 10 to 30 minutes.
> 2012-01-27 13:18:44,794 INFO  
> [org.springframework.jms.listener.SimpleMessageListenerContainer] Trying to 
> recover from JMS Connection exception: javax.jms.JMSException: Could not post 
> command: KeepAliveInfo {} due to: java.net.SocketException: Connection reset
> 2012-01-27 13:18:44,799 ERROR 
> [org.springframework.jms.listener.SimpleMessageListenerContainer] Encountered 
> non-recoverable JMSException
> javax.jms.JMSException: Could not post command: KeepAliveInfo {} due to: 
> java.net.SocketException: Connection reset
> at 
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> at 
> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1841)
> at 
> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1858)
> at 
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:126)
> at 
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
> at 
> org.apache.activemq.transport.InactivityMonitor.onException(InactivityMonitor.java:265)
> at 
> org.apache.activemq.transport.InactivityMonitor$3.run(InactivityMonitor.java:156)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: java.io.IOException: Could not post command: KeepAliveInfo {} due 
> to: java.net.SocketException: Connection reset
> at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:33)
> at 
> org.apache.activemq.transport.http.HttpClientTransport.oneway(HttpClientTransport.java:103)
> at 
> org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:254)
> at 
> org.apache.activemq.transport.InactivityMonitor$3.run(InactivityMonitor.java:154)
> ... 3 more
> Caused by: java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
> at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
> at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
> at 
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
> at 
> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
> at 
> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
> at 
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> at 
> org.apache.activemq.transport.http.HttpClientTransport.oneway(HttpClientTransport.java:91)
> ... 5 more



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (ARTEMIS-3134) hostname-address shows extra '/' in console

2021-06-20 Thread Erwin Dondorp (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwin Dondorp updated ARTEMIS-3134:
---
Description: 
In "Browse Connections", both the local and the remote address of a connection 
show an additional '/'. The same happens on "Browse Producers" and " Browse 
Consumers" .

This may have been an attempt to show both the hostname and the ip-number 
separated (also) by '/'.

Snippet from "Browse Connections":

!image-2021-02-21-22-35-45-667.png!
  

  was:
In "Browse Connections", both the local and the remote address of a connection 
show an additional '/'. The same happens on "Browse Producers".

This may have been an attempt to show both the hostname and the ip-number 
separated (also) by '/'.

Snippet from "Browse Connections":

!image-2021-02-21-22-35-45-667.png!
 


> hostname-address shows extra '/' in console
> ---
>
> Key: ARTEMIS-3134
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3134
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: image-2021-02-21-22-35-45-667.png
>
>
> In "Browse Connections", both the local and the remote address of a 
> connection show an additional '/'. The same happens on "Browse Producers" and 
> " Browse Consumers" .
> This may have been an attempt to show both the hostname and the ip-number 
> separated (also) by '/'.
> Snippet from "Browse Connections":
> !image-2021-02-21-22-35-45-667.png!
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (ARTEMIS-3343) duplicate address-setting gets lost

2021-06-20 Thread Erwin Dondorp (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwin Dondorp updated ARTEMIS-3343:
---
Description: 
In setting file {{broker.xml}}, it is possible to register multiple 
{{address-setting}} blocks for the same {{match}}. But because these blocks are 
put in a {{Map}} (in 
{{org.apache.activemq.artemis.core.deployers.impl.parseAddressSettings()}}), 
any previous block with the same {{match}} will be effectively ignored.

This may also happen for some of the other named blocks.

My suggestion is to raise an error when configuration information is lost.

  was:
In setting file `broker.xml`, it is possible to register multiple 
`address-setting` blocks for the same `match`. But because these blocks are put 
in a `Map` (in 
`org.apache.activemq.artemis.core.deployers.impl.parseAddressSettings()`), any 
previous block with the same `match` will be effectively ignored.

This may also happen for some of the other named blocks.

My suggestion is to raise an error when configuration information is lost.


> duplicate address-setting gets lost
> ---
>
> Key: ARTEMIS-3343
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3343
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> In setting file {{broker.xml}}, it is possible to register multiple 
> {{address-setting}} blocks for the same {{match}}. But because these blocks 
> are put in a {{Map}} (in 
> {{org.apache.activemq.artemis.core.deployers.impl.parseAddressSettings()}}), 
> any previous block with the same {{match}} will be effectively ignored.
> This may also happen for some of the other named blocks.
> My suggestion is to raise an error when configuration information is lost.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (ARTEMIS-3209) improve error message AMQ222186: unable to authorise cluster control

2021-06-20 Thread Justin Bertram (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-3209.
-
Fix Version/s: 2.18.0
   Resolution: Fixed

> improve error message AMQ222186: unable to authorise cluster control
> 
>
> Key: ARTEMIS-3209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.18.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am converting my Artemis systems to use SSL on every connection. this 
> includes the broker connections as needed for the clustering. At this stage, 
> I did not yet provide the correct trust-store and got an error for that.
> The error message that was shown is "AMQ222186: unable to authorise cluster 
> control".
> That message is not very informative. Looking at 
> {{ClusterConnectionImpl.java(566)}}, I see that the original exception is 
> ignored and replaced by this error message.
> My suggestion is to include the original exception with the message.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (ARTEMIS-3286) address or queue with COMMA is displayed wrong in web console

2021-06-20 Thread Erwin Dondorp (Jira)


[ 
https://issues.apache.org/jira/browse/ARTEMIS-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364274#comment-17364274
 ] 

Erwin Dondorp edited comment on ARTEMIS-3286 at 6/20/21, 9:56 PM:
--

[~brusdev] that looks like a real solution, nice!

But can I propose a simple workaround (for the command-line case) to be applied 
as well? It is in PR 
[#3627|https://github.com/apache/activemq-artemis/pull/3627]


was (Author: erwindon):
[~brusdev] that looks like a real solution, nice!

But can I propose a simple workaround to be applied as well? It is in PR 
[#3627|https://github.com/apache/activemq-artemis/pull/3627]

> address or queue with COMMA is displayed wrong in web console
> -
>
> Key: ARTEMIS-3286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2021-05-06-22-35-19-449.png
>
>
> when creating an address with a COMMA in its name, the address is displayed 
> in an odd fashion.
> Use "Create address" and enter {{x,y}} (i.e. x-comma-y)
>  See:
>  !image-2021-05-06-22-35-19-449.png!  
> A similar thing happens for queues containing a COMMA.
> NOTE:
> I normally do not create objects with a COMMA in their name, but the 
> commandline does.
> e.g.: {{artemis consumer --destination topic://foobar --durable --clientID 
> myclientid}}
> This creates a queue named {{myclientid.Consumer ActiveMQTopic[foobar], 
> thread=0}} under the given address.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (ARTEMIS-3157) uneven number of connections in a cluster

2021-06-20 Thread Erwin Dondorp (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwin Dondorp updated ARTEMIS-3157:
---
Description: 
Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a 
fresh virtual disk. no other constructions (bridges/federation/brokerconn/etc) 
and also no clients.

On each master nodes, the 2 static connections to the other master nodes are 
visible, and each is marked with the dedicated cluster username. so that part 
seems ok.

but without any clients having connected, there are additional connections. the 
amount is not the same in each master node. Some connections show "127.0.0.1" 
as address, something that is not in my configuration. none of the extra 
connections have any sessions.

the details of an example:
* broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from 
backup of broker3
* broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from 
broker3; 1 extra to/from slave of broker3
* broker3: 1 connection to own slave; no other extra connections

the exact amount of connections varies a little between startups and also seems 
to depend on the exact startup sequence.

my assumption is that these connections should not be present, and that this is 
not intended, hence this report. my wild guess is that these are remnants from 
connections that did not succeed due to the cluster not fully available yet.

When the cluster is started one node at a time, the effect seems to exists only 
on the first node that was started.

Note: not related to ARTEMIS-2870 as this report is still valid in 
2.18.0-20210322.234647-43.

  was:
Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a 
fresh virtual disk. no other constructions (bridges/federation/brokerconn/etc) 
and also no clients.

On each master nodes, the 2 static connections to the other master nodes are 
visible, and each is marked with the dedicated cluster username. so that part 
seems ok.

but without any clients having connected, there are additional connections. the 
amount is not the same in each master node. Some connections show "127.0.0.1" 
as address, something that is not in my configuration. none of the extra 
connections have any sessions.

the details of an example:
* broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from 
backup of broker3
* broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from 
broker3; 1 extra to/from slave of broker3
* broker3: 1 connection to own slave; no other extra connections

the exact amount of connections varies a little between startups and also seems 
to depend on the exact startup sequence.

my assumption is that these connections should not be present, and that this is 
not intended, hence this report. my wild guess is that these are remnants from 
connections that did not success due to the cluster not fully available yet.

When the cluster is started one node at a time, the effect seems to exists only 
on the first node that was started.

Note: not related to ARTEMIS-2870 as this report is still valid in 
2.18.0-20210322.234647-43.


> uneven number of connections in a cluster
> -
>
> Key: ARTEMIS-3157
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3157
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a 
> fresh virtual disk. no other constructions 
> (bridges/federation/brokerconn/etc) and also no clients.
> On each master nodes, the 2 static connections to the other master nodes are 
> visible, and each is marked with the dedicated cluster username. so that part 
> seems ok.
> but without any clients having connected, there are additional connections. 
> the amount is not the same in each master node. Some connections show 
> "127.0.0.1" as address, something that is not in my configuration. none of 
> the extra connections have any sessions.
> the details of an example:
> * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra 
> to/from backup of broker3
> * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra 
> to/from broker3; 1 extra to/from slave of broker3
> * broker3: 1 connection to own slave; no other extra connections
> the exact amount of connections varies a little between startups and also 
> seems to depend on the exact startup sequence.
> my assumption is that these connections should not be present, and that this 
> is not intended, hence this report. my wild guess is that these are remnants 
> from connections that did not succeed due to the cluster not fully available 
> yet.
> When the cluster is started one node

[jira] [Updated] (ARTEMIS-3209) improve error message AMQ222186: unable to authorise cluster control

2021-06-20 Thread Erwin Dondorp (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwin Dondorp updated ARTEMIS-3209:
---
Description: 
I am converting my Artemis systems to use SSL on every connection. this 
includes the broker connections as needed for the clustering. At this stage, I 
did not yet provide the correct trust-store and got an error for that.
The error message that was shown is "AMQ222186: unable to authorise cluster 
control".
That message is not very informative. Looking at 
{{ClusterConnectionImpl.java(566)}}, I see that the original exception is 
ignored and replaced by this error message.

My suggestion is to include the original exception with the message.

  was:
I am converting my Artemis systems to use SSL on every connection. this 
includes the broker connections as needed for the clustering. At this stage, 
I've did not yet provide the correct trust-store and got an error for that.
The error message that was shown is "AMQ222186: unable to authorise cluster 
control".
That message is not very informative. Looking at 
{{ClusterConnectionImpl.java(566)}}, I see that the original exception is 
ignored and replaced by this error message.

My suggestion is to include the original exception with the message.


> improve error message AMQ222186: unable to authorise cluster control
> 
>
> Key: ARTEMIS-3209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am converting my Artemis systems to use SSL on every connection. this 
> includes the broker connections as needed for the clustering. At this stage, 
> I did not yet provide the correct trust-store and got an error for that.
> The error message that was shown is "AMQ222186: unable to authorise cluster 
> control".
> That message is not very informative. Looking at 
> {{ClusterConnectionImpl.java(566)}}, I see that the original exception is 
> ignored and replaced by this error message.
> My suggestion is to include the original exception with the message.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (ARTEMIS-3359) Auto-Create of non-durable queue not possible

2021-06-20 Thread Rene Koch (Jira)
Rene Koch created ARTEMIS-3359:
--

 Summary: Auto-Create of non-durable queue not possible
 Key: ARTEMIS-3359
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3359
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.16.0
Reporter: Rene Koch


I have a application in which I want to have 1 durable and 1 non-durable queue 
in Active MQ Artemis. For connecting to this message bus I use amqpnetlite 
(https://github.com/Azure/amqpnetlite)

 
{code:java}
  var source = new Source()
{
};

if (durable)
{
source.Address = amqpAddressConverter.GetSubscriberAddress(address, 
useLoadBalancing);
source.Durable = 1;
source.ExpiryPolicy = new Symbol("never");
source.DistributionMode = new Symbol("copy");
}
else
{
source.Address = amqpAddressConverter.GetSubscriberAddress(address);
source.Durable = 0;
}

var receiverLink = new ReceiverLink(session, linkName, source, null); 
{code}
{{}}
So this is my receiver link. As shown I set the Durable uint of the Source 
which will given into the ReceiverLink.

Because as I saw in the Active MQ Artemis documentation, that the Durable is a 
boolean but within the amqpnetlite library it is an uint my understanding is 
that everything over 0 should be true and 0 should be false. (Seen here: 
[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-terminus-durability)]

At first the behaviour was very strange: Even when the Aretemis Web interface 
was shown a queue as durable it would be deleted as soon as no consumer would 
be connected.

I found this:
 
[https://stackoverflow.com/questions/66360625/activemq-artemis-queue-deleted-after-shutdown-of-consuming-client]
 which describes that even durable queues get deleted because of the default 
behaviour.

So I changed the broker.xml and set AUTO-DELETE-QUEUE to false.

Since then the behaviour completly switched:
 Both (durable = 1 and durable = 0) queues are being still there after the 
connection disconnected.

What I saw, either the configuration in the broker.xml - every queue will be 
durable = true, it doesn't mather what I set within the Link.

So how to create a durable and a non-durable connection correctly?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (ARTEMIS-3353) add acceptor parameter coreMinLargeMessageSize for CORE protocol

2021-06-20 Thread Erwin Dondorp (Jira)


 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwin Dondorp closed ARTEMIS-3353.
--
Resolution: Fixed

[~jbertram] thanks for the explanation!

> add acceptor parameter coreMinLargeMessageSize for CORE protocol
> 
>
> Key: ARTEMIS-3353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3353
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> The handling of large messages differs significantly between messaging 
> protocols.
>  See also 
> [https://activemq.apache.org/components/artemis/documentation/latest/large-messages.html]
> For CORE, currently, the producer decides on the fact whether a message is 
> large. It does that by using {{minLargeMessageSize=12345}} (default=100K) in 
> the _connection_-url. The client uses this value to determine whether it is 
> large size.
>  For AMQP, currently, the broker decides on that fact. It does that by using 
> {{amqpMinLargeMessageSize=12345}} in the _acceptor_-url.
>  This means that the responsibility is not always in the same place. And the 
> responsibility is therefore not with the same teams, as we have a team that 
> maintains the broker and teams that maintain consumer/producer applications. 
> And there is also some freedom in using amqp and/or core.
> My goal is to make the client connections as simple as possible.
> My proposal is to add parameter {{coreMinLargeMessageSize}} to the acceptor 
> urls for use by the CORE protocol. When the value is set, it indicates that 
> the large message flag must be reset by the broker based on that 
> parameter-value. Not setting the value or using {{""}} leaves the original 
> indicator alone.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQ-8302?focusedWorklogId=612386&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-612386
 ]

ASF GitHub Bot logged work on AMQ-8302:
---

Author: ASF GitHub Bot
Created on: 20/Jun/21 16:56
Start Date: 20/Jun/21 16:56
Worklog Time Spent: 10m 
  Work Description: jbonofre merged pull request #671:
URL: https://github.com/apache/activemq/pull/671


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 612386)
Remaining Estimate: 0h
Time Spent: 10m

> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366215#comment-17366215
 ] 

ASF subversion and git services commented on AMQ-8302:
--

Commit b94267c376837fd1c2075fe7d576d01ea098952b in activemq's branch 
refs/heads/main from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=b94267c ]

Merge pull request #671 from jbonofre/AMQ-8302

[AMQ-8302] Extend Camel import version range to avoid refresh on Karaf

> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366213#comment-17366213
 ] 

ASF subversion and git services commented on AMQ-8302:
--

Commit 871f9267657caf0088b66011ad41bad5106cff6d in activemq's branch 
refs/heads/main from jbonofre
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=871f926 ]

[AMQ-8302] Extend Camel import version range to avoid refresh on Karaf


> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread Jira


 [ 
https://issues.apache.org/jira/browse/AMQ-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved AMQ-8301.
---
Resolution: Fixed

> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread Jira


 [ 
https://issues.apache.org/jira/browse/AMQ-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved AMQ-8302.
---
Resolution: Fixed

> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366214#comment-17366214
 ] 

ASF subversion and git services commented on AMQ-8302:
--

Commit b94267c376837fd1c2075fe7d576d01ea098952b in activemq's branch 
refs/heads/main from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=b94267c ]

Merge pull request #671 from jbonofre/AMQ-8302

[AMQ-8302] Extend Camel import version range to avoid refresh on Karaf

> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8302) Extend Camel version range in Karaf features to avoid refresh

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366211#comment-17366211
 ] 

ASF subversion and git services commented on AMQ-8302:
--

Commit 4f3e8b0a4951f60d9d1232d96cf20eb68e4cfd01 in activemq's branch 
refs/heads/activemq-5.16.x from jbonofre
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=4f3e8b0 ]

[AMQ-8302] Extend Camel import version range to avoid refresh on Karaf


> Extend Camel version range in Karaf features to avoid refresh
> -
>
> Key: AMQ-8302
> URL: https://issues.apache.org/jira/browse/AMQ-8302
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Camel, OSGi/Karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366212#comment-17366212
 ] 

ASF subversion and git services commented on AMQ-8301:
--

Commit 51fa53977bdccaf902202c0597f4e6ca84969b69 in activemq's branch 
refs/heads/activemq-5.16.x from Matt Pavlovich
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=51fa539 ]

[AMQ-8301] Upgrade to Jetty 9.4.42.v20210604

(cherry picked from commit c8e7ef3e001f94cb744e0512a152274d4c0b13ef)


> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366209#comment-17366209
 ] 

ASF subversion and git services commented on AMQ-8301:
--

Commit 9e77e308f8ced15d9db8f42519603a3e7282bc40 in activemq's branch 
refs/heads/main from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=9e77e30 ]

Merge pull request #670 from mattrpav/AMQ-8301

[AMQ-8301] Upgrade to Jetty 9.4.42.v20210604

> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQ-8301?focusedWorklogId=612385&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-612385
 ]

ASF GitHub Bot logged work on AMQ-8301:
---

Author: ASF GitHub Bot
Created on: 20/Jun/21 16:54
Start Date: 20/Jun/21 16:54
Worklog Time Spent: 10m 
  Work Description: jbonofre merged pull request #670:
URL: https://github.com/apache/activemq/pull/670


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 612385)
Remaining Estimate: 0h
Time Spent: 10m

> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366210#comment-17366210
 ] 

ASF subversion and git services commented on AMQ-8301:
--

Commit 9e77e308f8ced15d9db8f42519603a3e7282bc40 in activemq's branch 
refs/heads/main from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=9e77e30 ]

Merge pull request #670 from mattrpav/AMQ-8301

[AMQ-8301] Upgrade to Jetty 9.4.42.v20210604

> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMQ-8301) Upgrade to Jetty 9.4.42.v20210604

2021-06-20 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/AMQ-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366208#comment-17366208
 ] 

ASF subversion and git services commented on AMQ-8301:
--

Commit c8e7ef3e001f94cb744e0512a152274d4c0b13ef in activemq's branch 
refs/heads/main from Matt Pavlovich
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c8e7ef3 ]

[AMQ-8301] Upgrade to Jetty 9.4.42.v20210604


> Upgrade to Jetty 9.4.42.v20210604
> -
>
> Key: AMQ-8301
> URL: https://issues.apache.org/jira/browse/AMQ-8301
> Project: ActiveMQ
>  Issue Type: Dependency upgrade
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.3
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)