date:20160701

[jira] [Commented] (AMQ-6194) Deleting a temporary queue creates a warning message in the broker

2016-07-01 Thread JIRA


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

Håkan Johansson commented on AMQ-6194:
--

In our production test environment this bug causes the ActiveMQ kahadb store 
limit to be reached, even though there is not a single message currently in the 
broker. The "data/kahadb" directory fills up with database log files, stopping 
the broker from working.

We have several clients using request-response where the response queue is a 
temporary queue. Each client has its own temporary queue which is reused for 
all requests during the lifetime of the client process, as recommended [by the 
ActiveMQ 
documentation|http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html].
When we look at the temp queues using hawtio we see that the _EnqueueCount_ is 
always two times the _DequeueCount_, even though no messages can be fetched 
from the queue, aka "ghost" messages.

Because of the seriousness of this issue I would consider this issue to be at 
least _Major_, not _Minor_ as it is today.

If we manually build ActiveMQ with this patch, then this issue goes away, but 
we would prefer to have an official release instead.
We would be very happy if a new release containing this fix could be 
prioritized.

> Deleting a temporary queue creates a warning message in the broker
> --
>
> Key: AMQ-6194
> URL: https://issues.apache.org/jira/browse/AMQ-6194
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMS client
>Affects Versions: 5.12.1, 5.13.1
>Reporter: David Dou
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0
>
> Attachments: AMQ6194Test.java
>
>
> When deleting a temporary queue, the ActiveMQ 5.13.1 (and 5.12.2) broker logs 
> the following warning message:
> {noformat}
> INFO  [ActiveMQ NIO Worker 111] [TempQueue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 on dispose, purge 
> of 1 pending messages: 
> org.apache.activemq.broker.region.cursors.VMPendingMessageCursor@e0f6196
> WARN  [ActiveMQ NIO Worker 111] [Queue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 after purge of 1 
> messages, message count stats report: 1
> {noformat}
> The cause of this warning seems to be the publication of a "ghost" message 
> when sending a single message on the temporary queue from a transacted 
> session, as demonstrated by this test class:
> {code:java}
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.jms.Connection;
> import javax.jms.JMSException;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TemporaryQueue;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class GhostMessageOnTempQueueWithTransactedSessionDemo {
> public static void main(final String[] args) throws JMSException {
> final ActiveMQConnectionFactory factory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection = null;
> Session session = null;
> MessageProducer producer = null;
> TemporaryQueue temporaryQueue = null;
> try {
> connection = factory.createConnection();
> connection.start();
> // The session has to be transacted for the second "ghost" 
> message to appear (see below).
> session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> // And the publication has to be on a temporary queue (if the 
> temporary queue is created by another process, the second "ghost" message 
> still appears).
> temporaryQueue = session.createTemporaryQueue();
> producer = session.createProducer(temporaryQueue);
> final TextMessage textMessage = session.createTextMessage();
> textMessage.setText("GhostMessageDemo@" + new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss,SSSZ").format(new Date()));
> producer.send(textMessage);
> // Here, in ActiveMQ 5.13.1 and 5.12.2, the message was sent but 
> cannot be browsed or consumed. It can however be seen in the JMX console with:
> // - EnqueueCount, that was increased by one;
> // - MemoryUsageByteCount (by sending huge messages of different 
> size to ensure that it is indeed the real message).
> // In ActiveMQ 5.10.2 (and 5.4.1), it is not sent (even though 
> SocketOutputStream.socketWrite is still called through TcpFormat.oneway?).
> session.commit();
> // Here, in ActiveMQ 5.13.1, a "ghost" message was sent 
> (EnqueueCount has increased by one again) and the real message is visible and 
> can be consumed.
> // If

[jira] [Created] (ARTEMIS-605) Add a configuration option to disable management messages processing

2016-07-01 Thread Lionel Cons (JIRA)

Lionel Cons created ARTEMIS-605:
---

 Summary: Add a configuration option to disable management messages 
processing
 Key: ARTEMIS-605
 URL: https://issues.apache.org/jira/browse/ARTEMIS-605
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Lionel Cons


According to the documentation, one can switch off the broker management via 
JMX using {{jmx-management-enabled}}.

I did not find a similar option to switch off the broker management via 
messages. One can configure it a bit ({{management-address}} and 
{{management-notification-address}}) but apparently not disable it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6230) Camel 2.17.0 breaks Karaf integration tests

2016-07-01 Thread Claus Ibsen (JIRA)


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

Claus Ibsen commented on AMQ-6230:
--

Around august or maybe into september when summer vacation is over

> Camel 2.17.0 breaks Karaf integration tests
> ---
>
> Key: AMQ-6230
> URL: https://issues.apache.org/jira/browse/AMQ-6230
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Affects Versions: 5.13.2
>Reporter: Christopher L. Shannon
>Assignee: Claus Ibsen
> Fix For: 5.14.0
>
>
> The new Camel version seems to cause the ActiveMQBrokerNdCamelFeatureTest 
> test to fail.
> https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Java8/lastBuild/org.apache.activemq$activemq-karaf-itest/testReport/org.apache.activemq.karaf.itest/ActiveMQBrokerNdCamelFeatureTest/test/
> It looks like a bunch of work was done with Karaf and to get rid of Spring DM 
> in the new version which is probably the issue as ActiveMQ still has the 
> Spring DM stuff laying around.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-606) [Artemis Testsuite] JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails

2016-07-01 Thread Erich Duda (JIRA)

Erich Duda created ARTEMIS-606:
--

 Summary: [Artemis Testsuite] 
JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
 Key: ARTEMIS-606
 URL: https://issues.apache.org/jira/browse/ARTEMIS-606
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Erich Duda


{code}
java.lang.AssertionError: did not received the expected JMSException
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.doCloseConnectionsForUser(JMSServerControl2Test.java:1136)
at 
org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.testCloseConnectionsForUserForInVM(JMSServerControl2Test.java:143)
{code}

{code}
11:49:34,359 INFO  [org.apache.activemq.artemis.core.server] #*#*# Starting 
test: testCloseConnectionsForUserForInVM()...
#test testCloseConnectionsForUserForInVM
11:49:34,394 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
Message Broker is starting with configuration Broker Configuration 
(clustered=false,journalDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/journal,bindingsDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/bindings,largeMessagesDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/large-msg,pagingDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/page)
11:49:34,395 INFO  [org.apache.activemq.artemis.core.server] AMQ221012: Using 
AIO Journal
11:49:34,397 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-server]. Adding protocol support for: CORE
11:49:34,399 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
AMQP
11:49:34,400 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
STOMP
11:49:34,401 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
for: OPENWIRE
11:49:34,403 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: 
HORNETQ
11:49:34,404 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
MQTT
11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221007: Server 
is now live
11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221001: Apache 
ActiveMQ Artemis Message Broker version 1.1.0.jboss-SNAPSHOT 
[nodeID=e915a1c8-3d47-11e6-a0a1-3172e2bd12af] 
11:49:34,606 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: trying 
to deploy queue jms.queue.97c12b14-0a31-4cb8-a1ad-5ba0217abb5f
11:49:34,650 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: trying 
to deploy queue jms.queue.66bdf106-b409-4e3c-b70b-d9918ea812c3
11:49:34,830 WARN  [org.apache.activemq.artemis.core.client] AMQ212037: 
Connection failure has been detected: AMQ119108: connections for user fakeUser 
closed by management [code=INTERNAL_ERROR]
11:49:34,830 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client 
connection failed, clearing up resources for session 
e94bcd00-3d47-11e6-a0a1-3172e2bd12af
11:49:34,831 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared 
up resources for session e94bcd00-3d47-11e6-a0a1-3172e2bd12af
11:49:34,846 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client 
connection failed, clearing up resources for session 
e94f9d91-3d47-11e6-a0a1-3172e2bd12af
11:49:34,848 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared 
up resources for session e94f9d91-3d47-11e6-a0a1-3172e2bd12af
11:49:34,853 WARN  [org.apache.activemq.artemis.jms.client] AMQ122000: I''m 
closing a JMS connection you left open. Please make sure you close all JMS 
connections explicitly before letting them go out of scope! see stacktrace to 
find out where it was created: java.lang.Exception
at 
org.apache.activemq.artemis.jms.client.ActiveMQConnection.(ActiveMQConnection.java:155)
 [:]
at

[jira] [Commented] (AMQ-6343) [MQTT] LWT doesn't work over a websocket connection

2016-07-01 Thread Timothy Bish (JIRA)


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

Timothy Bish commented on AMQ-6343:
---

Seems plausible, a unit test might be a good idea to try it out ;)

> [MQTT] LWT doesn't work over a websocket connection
> ---
>
> Key: AMQ-6343
> URL: https://issues.apache.org/jira/browse/AMQ-6343
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.3
> Environment: GNU/Linux Debian 8.3
>Reporter: Sylvain Maucourt
>
> I use several services, some of them connect over tcp and the LWT works 
> properly.
> I use several clients from a webapp' connected over a websocket link.
> i use a javascript code:
> {code:javascript}
> var i_am_disconnected = new Paho.MQTT.Message(JSON.stringify({
> version: 1,
> state: 0
>   }));
>   i_am_disconnected.destinationName = "device/" + _token + "/ping";
>   i_am_disconnected.retained = true;
>   i_am_disconnected.qos = 1;
> client.onConnectionLost = onConnectionLost;
>   client.connect(…
> {code}
> i traced the ActiveMQ log, i can see that the disconnection is detected, but 
> i didn't receive my LWT message. (again, my LWT works when I use a tcp 
> connexion)
> {code}
> 2016-07-01 00:07:51,329 | INFO  | addConnection() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ConnectionInfo {commandId = 0, responseRequired = true, connectionId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27, clientId = 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64, clientIp = ws://192.168.0.2:42372, 
> userName = 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64, 
> password = *, brokerPath = null, brokerMasterConnector = false, 
> manageable = false, clientMaster = true, faultTolerant = false, 
> failoverReconnect = false} | 
> com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-40
> 2016-07-01 00:07:51,333 | INFO  | addProducer() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ProducerInfo {commandId = 2, responseRequired = true, producerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
> null, brokerPath = null, dispatchAsync = false, windowSize = 0, sentCount = 
> 0} | com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-40
> 2016-07-01 00:07:51,423 | INFO  | send() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> send: ActiveMQBytesMessage {commandId = 3, responseRequired = true, messageId 
> = ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1:1, 
> originalDestination = null, originalTransactionId = null, producerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
> topic://device.bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64.ping,
>  transactionId = null, expiration = 0, timestamp = 1467324471422, arrival = 
> 0, brokerInTime = 0, brokerOutTime = 0, correlationId = null, replyTo = null, 
> persistent = false, type = null, priority = 4, groupID = null, groupSequence 
> = 0, targetConsumerId = null, compressed = false, userID = null, content = 
> org.apache.activemq.util.ByteSequence@335bf90b, marshalledProperties = null, 
> dataStructure = null, redeliveryCounter = 0, size = 0, properties = 
> {ActiveMQ.MQTT.QoS=1, ActiveMQ.Retain=true}, readOnlyProperties = true, 
> readOnlyBody = true, droppable = false, jmsXGroupFirstForConsumer = false} 
> ActiveMQBytesMessage{ bytesOut = null, dataOut = null, dataIn = null } 
> payload: {"version":1,"state":2,"timestamp":1467324470.015} | 
> com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-41
> 2016-07-01 00:07:51,447 | INFO  | addConsumer() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ConsumerInfo {commandId = 4, responseRequired = true, consumerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
> topic://mobile.167e0de6e20b55cc318aacb74f31752e2bffd339.*.position, 
> prefetchSize = 32767, maximumPendingMessageLimit = 0, browser = false, 
> dispatchAsync = true, selector = null, clientId = null, subscriptionName = 
> null, noLocal = false, exclusive = false, retroactive = true, priority = 0, 
> brokerPath = null, optimizedAcknowledge = false, noRangeAcks = false, 
> additionalPredicate = null} | 
> com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-39
> 2016-07-01 00:07:51,451 | INFO  |

[jira] [Commented] (ARTEMIS-606) [Artemis Testsuite] JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-606:


GitHub user dudaerich opened a pull request:

https://github.com/apache/activemq-artemis/pull/614

ARTEMIS-606 JMSServerControl2Test#testCloseConsumerConnectionsForAddr…

…essForInVM fails

Based on log it is clear that the connection was closed by Finalizer before 
the failure
was caused by the test itself. Since the connection variable is not 
referenced in the
code anymore, JVM concludes it can destroy the object. Especially IBM JDK 
does it very
fast.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-606

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/614.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #614


commit 058a6ee880270834f9c886c1ec7eb72c2103cdca
Author: Erich Duda 
Date:   2016-07-01T12:54:18Z

ARTEMIS-606 
JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails

Based on log it is clear that the connection was closed by Finalizer before 
the failure
was caused by the test itself. Since the connection variable is not 
referenced in the
code anymore, JVM concludes it can destroy the object. Especially IBM JDK 
does it very
fast.




> [Artemis Testsuite] 
> JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
> -
>
> Key: ARTEMIS-606
> URL: https://issues.apache.org/jira/browse/ARTEMIS-606
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: did not received the expected JMSException
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.doCloseConnectionsForUser(JMSServerControl2Test.java:1136)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.testCloseConnectionsForUserForInVM(JMSServerControl2Test.java:143)
> {code}
> {code}
> 11:49:34,359 INFO  [org.apache.activemq.artemis.core.server] #*#*# Starting 
> test: testCloseConnectionsForUserForInVM()...
> #test testCloseConnectionsForUserForInVM
> 11:49:34,394 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/journal,bindingsDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/bindings,largeMessagesDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/large-msg,pagingDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/page)
> 11:49:34,395 INFO  [org.apache.activemq.artemis.core.server] AMQ221012: Using 
> AIO Journal
> 11:49:34,397 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 11:49:34,399 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 11:49:34,400 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 11:49:34,401 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 11:49:34,403 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 11:49:34,404 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221007:

[jira] [Commented] (AMQ-6194) Deleting a temporary queue creates a warning message in the broker

2016-07-01 Thread JIRA


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

Håkan Johansson commented on AMQ-6194:
--

Thank you for your quick response.

> Deleting a temporary queue creates a warning message in the broker
> --
>
> Key: AMQ-6194
> URL: https://issues.apache.org/jira/browse/AMQ-6194
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMS client
>Affects Versions: 5.12.1, 5.13.1
>Reporter: David Dou
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
> Attachments: AMQ6194Test.java
>
>
> When deleting a temporary queue, the ActiveMQ 5.13.1 (and 5.12.2) broker logs 
> the following warning message:
> {noformat}
> INFO  [ActiveMQ NIO Worker 111] [TempQueue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 on dispose, purge 
> of 1 pending messages: 
> org.apache.activemq.broker.region.cursors.VMPendingMessageCursor@e0f6196
> WARN  [ActiveMQ NIO Worker 111] [Queue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 after purge of 1 
> messages, message count stats report: 1
> {noformat}
> The cause of this warning seems to be the publication of a "ghost" message 
> when sending a single message on the temporary queue from a transacted 
> session, as demonstrated by this test class:
> {code:java}
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.jms.Connection;
> import javax.jms.JMSException;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TemporaryQueue;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class GhostMessageOnTempQueueWithTransactedSessionDemo {
> public static void main(final String[] args) throws JMSException {
> final ActiveMQConnectionFactory factory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection = null;
> Session session = null;
> MessageProducer producer = null;
> TemporaryQueue temporaryQueue = null;
> try {
> connection = factory.createConnection();
> connection.start();
> // The session has to be transacted for the second "ghost" 
> message to appear (see below).
> session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> // And the publication has to be on a temporary queue (if the 
> temporary queue is created by another process, the second "ghost" message 
> still appears).
> temporaryQueue = session.createTemporaryQueue();
> producer = session.createProducer(temporaryQueue);
> final TextMessage textMessage = session.createTextMessage();
> textMessage.setText("GhostMessageDemo@" + new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss,SSSZ").format(new Date()));
> producer.send(textMessage);
> // Here, in ActiveMQ 5.13.1 and 5.12.2, the message was sent but 
> cannot be browsed or consumed. It can however be seen in the JMX console with:
> // - EnqueueCount, that was increased by one;
> // - MemoryUsageByteCount (by sending huge messages of different 
> size to ensure that it is indeed the real message).
> // In ActiveMQ 5.10.2 (and 5.4.1), it is not sent (even though 
> SocketOutputStream.socketWrite is still called through TcpFormat.oneway?).
> session.commit();
> // Here, in ActiveMQ 5.13.1, a "ghost" message was sent 
> (EnqueueCount has increased by one again) and the real message is visible and 
> can be consumed.
> // If rollback is called instead, the real message stays (and 
> cannot be consumed since the "ghost" message is not sent).
> } finally {
> if (producer != null)
> producer.close();
> if (temporaryQueue != null)
> // Here, if there was a consumer on the queue, it would have 
> consumed the real message, leaving the "ghost" message that lead to the 
> broker warning.
> temporaryQueue.delete();
> if (session != null)
> session.close();
> if (connection != null) {
> connection.stop();
> connection.close();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6343) [MQTT] LWT doesn't work over a websocket connection

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-6343:
-

[~tabish121],

I looked at this briefly and it seems like in the 
[onWebSocketClose|https://github.com/apache/activemq/blob/activemq-5.13.3/activemq-http/src/main/java/org/apache/activemq/transport/ws/jetty9/MQTTSocket.java#L81]
 method of MQTTSocket we should be checking if a disconnect frame has been 
received already prior to close and if not then call 
getProtocolConverter().onTransportError() which should take care of LWT.  Right 
now that method just sends a disconnect frame again so LWT will never work if 
the connection was just closed prior to receiving disconnect.

> [MQTT] LWT doesn't work over a websocket connection
> ---
>
> Key: AMQ-6343
> URL: https://issues.apache.org/jira/browse/AMQ-6343
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.3
> Environment: GNU/Linux Debian 8.3
>Reporter: Sylvain Maucourt
>
> I use several services, some of them connect over tcp and the LWT works 
> properly.
> I use several clients from a webapp' connected over a websocket link.
> i use a javascript code:
> {code:javascript}
> var i_am_disconnected = new Paho.MQTT.Message(JSON.stringify({
> version: 1,
> state: 0
>   }));
>   i_am_disconnected.destinationName = "device/" + _token + "/ping";
>   i_am_disconnected.retained = true;
>   i_am_disconnected.qos = 1;
> client.onConnectionLost = onConnectionLost;
>   client.connect(…
> {code}
> i traced the ActiveMQ log, i can see that the disconnection is detected, but 
> i didn't receive my LWT message. (again, my LWT works when I use a tcp 
> connexion)
> {code}
> 2016-07-01 00:07:51,329 | INFO  | addConnection() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ConnectionInfo {commandId = 0, responseRequired = true, connectionId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27, clientId = 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64, clientIp = ws://192.168.0.2:42372, 
> userName = 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64, 
> password = *, brokerPath = null, brokerMasterConnector = false, 
> manageable = false, clientMaster = true, faultTolerant = false, 
> failoverReconnect = false} | 
> com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-40
> 2016-07-01 00:07:51,333 | INFO  | addProducer() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ProducerInfo {commandId = 2, responseRequired = true, producerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
> null, brokerPath = null, dispatchAsync = false, windowSize = 0, sentCount = 
> 0} | com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-40
> 2016-07-01 00:07:51,423 | INFO  | send() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> send: ActiveMQBytesMessage {commandId = 3, responseRequired = true, messageId 
> = ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1:1, 
> originalDestination = null, originalTransactionId = null, producerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
> topic://device.bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64.ping,
>  transactionId = null, expiration = 0, timestamp = 1467324471422, arrival = 
> 0, brokerInTime = 0, brokerOutTime = 0, correlationId = null, replyTo = null, 
> persistent = false, type = null, priority = 4, groupID = null, groupSequence 
> = 0, targetConsumerId = null, compressed = false, userID = null, content = 
> org.apache.activemq.util.ByteSequence@335bf90b, marshalledProperties = null, 
> dataStructure = null, redeliveryCounter = 0, size = 0, properties = 
> {ActiveMQ.MQTT.QoS=1, ActiveMQ.Retain=true}, readOnlyProperties = true, 
> readOnlyBody = true, droppable = false, jmsXGroupFirstForConsumer = false} 
> ActiveMQBytesMessage{ bytesOut = null, dataOut = null, dataIn = null } 
> payload: {"version":1,"state":2,"timestamp":1467324470.015} | 
> com.deveryware.deverylight.activemq.TokenAuthenticationBroker | 
> qtp1143988572-41
> 2016-07-01 00:07:51,447 | INFO  | addConsumer() clientId: 
> 60badfb1-3e6d-4637-b4ec-16b557d7db64 userName: 
> bd525936-5238-4410-9579-79f8dfb27ea4::60badfb1-3e6d-4637-b4ec-16b557d7db64 
> info: ConsumerInfo {commandId = 4, responseRequired = true, consumerId = 
> ID:deverylight-all-snapshot-42229-1467323807294-3:27:-1:1, destination = 
>

[jira] [Updated] (AMQ-6194) Deleting a temporary queue creates a warning message in the broker

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon updated AMQ-6194:

Fix Version/s: 5.13.4

> Deleting a temporary queue creates a warning message in the broker
> --
>
> Key: AMQ-6194
> URL: https://issues.apache.org/jira/browse/AMQ-6194
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMS client
>Affects Versions: 5.12.1, 5.13.1
>Reporter: David Dou
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
> Attachments: AMQ6194Test.java
>
>
> When deleting a temporary queue, the ActiveMQ 5.13.1 (and 5.12.2) broker logs 
> the following warning message:
> {noformat}
> INFO  [ActiveMQ NIO Worker 111] [TempQueue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 on dispose, purge 
> of 1 pending messages: 
> org.apache.activemq.broker.region.cursors.VMPendingMessageCursor@e0f6196
> WARN  [ActiveMQ NIO Worker 111] [Queue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 after purge of 1 
> messages, message count stats report: 1
> {noformat}
> The cause of this warning seems to be the publication of a "ghost" message 
> when sending a single message on the temporary queue from a transacted 
> session, as demonstrated by this test class:
> {code:java}
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.jms.Connection;
> import javax.jms.JMSException;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TemporaryQueue;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class GhostMessageOnTempQueueWithTransactedSessionDemo {
> public static void main(final String[] args) throws JMSException {
> final ActiveMQConnectionFactory factory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection = null;
> Session session = null;
> MessageProducer producer = null;
> TemporaryQueue temporaryQueue = null;
> try {
> connection = factory.createConnection();
> connection.start();
> // The session has to be transacted for the second "ghost" 
> message to appear (see below).
> session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> // And the publication has to be on a temporary queue (if the 
> temporary queue is created by another process, the second "ghost" message 
> still appears).
> temporaryQueue = session.createTemporaryQueue();
> producer = session.createProducer(temporaryQueue);
> final TextMessage textMessage = session.createTextMessage();
> textMessage.setText("GhostMessageDemo@" + new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss,SSSZ").format(new Date()));
> producer.send(textMessage);
> // Here, in ActiveMQ 5.13.1 and 5.12.2, the message was sent but 
> cannot be browsed or consumed. It can however be seen in the JMX console with:
> // - EnqueueCount, that was increased by one;
> // - MemoryUsageByteCount (by sending huge messages of different 
> size to ensure that it is indeed the real message).
> // In ActiveMQ 5.10.2 (and 5.4.1), it is not sent (even though 
> SocketOutputStream.socketWrite is still called through TcpFormat.oneway?).
> session.commit();
> // Here, in ActiveMQ 5.13.1, a "ghost" message was sent 
> (EnqueueCount has increased by one again) and the real message is visible and 
> can be consumed.
> // If rollback is called instead, the real message stays (and 
> cannot be consumed since the "ghost" message is not sent).
> } finally {
> if (producer != null)
> producer.close();
> if (temporaryQueue != null)
> // Here, if there was a consumer on the queue, it would have 
> consumed the real message, leaving the "ghost" message that lead to the 
> broker warning.
> temporaryQueue.delete();
> if (session != null)
> session.close();
> if (connection != null) {
> connection.stop();
> connection.close();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6194) Deleting a temporary queue creates a warning message in the broker

2016-07-01 Thread ASF subversion and git services (JIRA)


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

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

Commit 7ddfa97d0173b07346ea8fdfcb8e6545766e0d39 in activemq's branch 
refs/heads/activemq-5.13.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7ddfa97 ]

https://issues.apache.org/jira/browse/AMQ-6194

Fixing an issue that caused statistics for a transactional temporary
queue to be updated twice by mistake.  Moved the statistics update into
tryOrderedCursorAdd so that the update is called immediately only if
not inside a transaction.

(cherry picked from commit 903dec615c7932475bd3e6cd869af25f01de64b2)


> Deleting a temporary queue creates a warning message in the broker
> --
>
> Key: AMQ-6194
> URL: https://issues.apache.org/jira/browse/AMQ-6194
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMS client
>Affects Versions: 5.12.1, 5.13.1
>Reporter: David Dou
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
> Attachments: AMQ6194Test.java
>
>
> When deleting a temporary queue, the ActiveMQ 5.13.1 (and 5.12.2) broker logs 
> the following warning message:
> {noformat}
> INFO  [ActiveMQ NIO Worker 111] [TempQueue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 on dispose, purge 
> of 1 pending messages: 
> org.apache.activemq.broker.region.cursors.VMPendingMessageCursor@e0f6196
> WARN  [ActiveMQ NIO Worker 111] [Queue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 after purge of 1 
> messages, message count stats report: 1
> {noformat}
> The cause of this warning seems to be the publication of a "ghost" message 
> when sending a single message on the temporary queue from a transacted 
> session, as demonstrated by this test class:
> {code:java}
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.jms.Connection;
> import javax.jms.JMSException;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TemporaryQueue;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class GhostMessageOnTempQueueWithTransactedSessionDemo {
> public static void main(final String[] args) throws JMSException {
> final ActiveMQConnectionFactory factory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection = null;
> Session session = null;
> MessageProducer producer = null;
> TemporaryQueue temporaryQueue = null;
> try {
> connection = factory.createConnection();
> connection.start();
> // The session has to be transacted for the second "ghost" 
> message to appear (see below).
> session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> // And the publication has to be on a temporary queue (if the 
> temporary queue is created by another process, the second "ghost" message 
> still appears).
> temporaryQueue = session.createTemporaryQueue();
> producer = session.createProducer(temporaryQueue);
> final TextMessage textMessage = session.createTextMessage();
> textMessage.setText("GhostMessageDemo@" + new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss,SSSZ").format(new Date()));
> producer.send(textMessage);
> // Here, in ActiveMQ 5.13.1 and 5.12.2, the message was sent but 
> cannot be browsed or consumed. It can however be seen in the JMX console with:
> // - EnqueueCount, that was increased by one;
> // - MemoryUsageByteCount (by sending huge messages of different 
> size to ensure that it is indeed the real message).
> // In ActiveMQ 5.10.2 (and 5.4.1), it is not sent (even though 
> SocketOutputStream.socketWrite is still called through TcpFormat.oneway?).
> session.commit();
> // Here, in ActiveMQ 5.13.1, a "ghost" message was sent 
> (EnqueueCount has increased by one again) and the real message is visible and 
> can be consumed.
> // If rollback is called instead, the real message stays (and 
> cannot be consumed since the "ghost" message is not sent).
> } finally {
> if (producer != null)
> producer.close();
> if (temporaryQueue != null)
> // Here, if there was a consumer on the queue, it would have 
> consumed the real message, leaving the "ghost" message that lead to the 
> broker warning.
> temporaryQueue.delete();
> if (session != null)
> session.close();
> if

[jira] [Commented] (AMQ-6194) Deleting a temporary queue creates a warning message in the broker

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-6194:
-

I actually meant to merge this earlier into a 5.13.x minor release but it was 
overlooked.  I went ahead and merged it now so it will be in 5.13.4 if released 
as well as 5.14.0.  I would like to start pushing for 5.14.0 soon but there are 
still a couple of issues to be worked out first so a 5.13.4 may end up being 
going out the door in the meantime as it probably has enough bug fixes by now 
that it can be released.

> Deleting a temporary queue creates a warning message in the broker
> --
>
> Key: AMQ-6194
> URL: https://issues.apache.org/jira/browse/AMQ-6194
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMS client
>Affects Versions: 5.12.1, 5.13.1
>Reporter: David Dou
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0, 5.13.4
>
> Attachments: AMQ6194Test.java
>
>
> When deleting a temporary queue, the ActiveMQ 5.13.1 (and 5.12.2) broker logs 
> the following warning message:
> {noformat}
> INFO  [ActiveMQ NIO Worker 111] [TempQueue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 on dispose, purge 
> of 1 pending messages: 
> org.apache.activemq.broker.region.cursors.VMPendingMessageCursor@e0f6196
> WARN  [ActiveMQ NIO Worker 111] [Queue] 
> temp-queue://ID:brokerHostname-57582-1455804170203-8569:1:1 after purge of 1 
> messages, message count stats report: 1
> {noformat}
> The cause of this warning seems to be the publication of a "ghost" message 
> when sending a single message on the temporary queue from a transacted 
> session, as demonstrated by this test class:
> {code:java}
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.jms.Connection;
> import javax.jms.JMSException;
> import javax.jms.MessageProducer;
> import javax.jms.Session;
> import javax.jms.TemporaryQueue;
> import javax.jms.TextMessage;
> import org.apache.activemq.ActiveMQConnectionFactory;
> public class GhostMessageOnTempQueueWithTransactedSessionDemo {
> public static void main(final String[] args) throws JMSException {
> final ActiveMQConnectionFactory factory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection = null;
> Session session = null;
> MessageProducer producer = null;
> TemporaryQueue temporaryQueue = null;
> try {
> connection = factory.createConnection();
> connection.start();
> // The session has to be transacted for the second "ghost" 
> message to appear (see below).
> session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> // And the publication has to be on a temporary queue (if the 
> temporary queue is created by another process, the second "ghost" message 
> still appears).
> temporaryQueue = session.createTemporaryQueue();
> producer = session.createProducer(temporaryQueue);
> final TextMessage textMessage = session.createTextMessage();
> textMessage.setText("GhostMessageDemo@" + new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss,SSSZ").format(new Date()));
> producer.send(textMessage);
> // Here, in ActiveMQ 5.13.1 and 5.12.2, the message was sent but 
> cannot be browsed or consumed. It can however be seen in the JMX console with:
> // - EnqueueCount, that was increased by one;
> // - MemoryUsageByteCount (by sending huge messages of different 
> size to ensure that it is indeed the real message).
> // In ActiveMQ 5.10.2 (and 5.4.1), it is not sent (even though 
> SocketOutputStream.socketWrite is still called through TcpFormat.oneway?).
> session.commit();
> // Here, in ActiveMQ 5.13.1, a "ghost" message was sent 
> (EnqueueCount has increased by one again) and the real message is visible and 
> can be consumed.
> // If rollback is called instead, the real message stays (and 
> cannot be consumed since the "ghost" message is not sent).
> } finally {
> if (producer != null)
> producer.close();
> if (temporaryQueue != null)
> // Here, if there was a consumer on the queue, it would have 
> consumed the real message, leaving the "ghost" message that lead to the 
> broker warning.
> temporaryQueue.delete();
> if (session != null)
> session.close();
> if (connection != null) {
> connection.stop();
> connection.close();
> }
> }
> }
> }
>

[jira] [Commented] (AMQ-6230) Camel 2.17.0 breaks Karaf integration tests

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-6230:
-

[~davsclaus], What is the time frame for a Camel 2.18.0 release? I would like 
to remove spring-dm but in camel version 2.17.x the camel-spring module still 
depends on spring dm.  Looks like that has been separated out in the latest 
2.18.0 snapshot builds so using version 2.18.0 would allow us to get rid of the 
spring dm dependency entirely.

> Camel 2.17.0 breaks Karaf integration tests
> ---
>
> Key: AMQ-6230
> URL: https://issues.apache.org/jira/browse/AMQ-6230
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Affects Versions: 5.13.2
>Reporter: Christopher L. Shannon
>Assignee: Claus Ibsen
> Fix For: 5.14.0
>
>
> The new Camel version seems to cause the ActiveMQBrokerNdCamelFeatureTest 
> test to fail.
> https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Java8/lastBuild/org.apache.activemq$activemq-karaf-itest/testReport/org.apache.activemq.karaf.itest/ActiveMQBrokerNdCamelFeatureTest/test/
> It looks like a bunch of work was done with Karaf and to get rid of Spring DM 
> in the new version which is probably the issue as ActiveMQ still has the 
> Spring DM stuff laying around.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6301) Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

2016-07-01 Thread Seth Leger (JIRA)


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

Seth Leger commented on AMQ-6301:
-

Hi Christopher, I just wanted to provide feedback that in our environment 
(Camel and ActiveMQ with only Blueprint inside Karaf) I don't think we have any 
dependency on camel-spring. If ActiveMQ removes its spring-dm dependency now, 
our environment would be free of spring-dm even though we also use Camel.

> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> 
>
> Key: AMQ-6301
> URL: https://issues.apache.org/jira/browse/AMQ-6301
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.13.0
>Reporter: Seth Leger
>  Labels: patch
>
> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> In commit 3a6d67e8f95320bea91b7c7106173c9b34773bc5, a test was fixed in issue 
> AMQ-4727 by reusing the spring-dm OsgiBundleXmlApplicationContext class 
> inside the ActiveMQServiceFactory managed service factory.
> To satisfy the import packages for activemq-osgi, the 'spring-dm' Karaf 
> feature was added to the main 'activemq-client' feature.
> This is problematic because loading the 'spring-dm' Karaf feature enables the 
> Spring DM deployer. This deployer is unnecessary in environments that rely on 
> Blueprint or CDI wiring and it may unexpectedly activate Spring DM bundles in 
> those environments. Because spring-dm was compiled against older versions of 
> Spring 3.0 and 3.1, it can also cause older versions of Spring features to be 
> loaded into the container.
> To avoid using the ‘spring-dm’ Karaf feature to provide the classes, I 
> propose embedding the spring-dm bundles inside activemq-osgi. Since they are 
> only used as library code to provide the BundleContext when parsing the 
> BrokerService context, they can be embedded safely without any dependency 
> issues.
> This is the root cause of the following issue:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-unable-to-start-bundle-activemq-osgi-5-13-0-td4044640.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-601) Add support for automatic configuration reloading

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram commented on ARTEMIS-601:


The current implementation idea for ARTEMIS-66 is to write changes made via the 
management API back to the XML so the broker.xml would still be the master and 
changes would survive restarts.  Your runtime configuration wouldn't be 
different from the configuration file.  

I assume all your management tools are all going to need to change to support 
Artemis' new XML format anyway.  Could they not change to execute a simple 
shell/perl/python script.  I'm not terribly familiar with Puppet.  Is it only 
able to modify text files?  If it's built for managing deployments and runtime 
configuration I'd be surprised if it didn't support JMX since that is the 
standard for managing Java applications.

> Add support for automatic configuration reloading
> -
>
> Key: ARTEMIS-601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-601
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> ActiveMQ 5.x does support automatic configuration reloading and this includes 
> security related configuration (amongst other things), see 
> http://activemq.apache.org/runtime-configuration.html.
> In our environment, it is very important to change the security settings 
> without having to restart the broker.This works fine with ActiveMQ 5.x and 
> the {{runtimeConfigurationPlugin}}.
> ARTEMIS-579 clarified the reload of the JAAS files. This is good but it is 
> only one half of the security related configuration since the rest appears in 
> {{}}.
> Could Artemis please also implement automatic configuration reloading, at 
> least for the security configuration?
> Of course, the more settings can be changed without restarting the broker, 
> the better...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-605) Add a configuration option to disable management messages processing

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram commented on ARTEMIS-605:


Can you elaborate on the use-case here a bit?  If you want to prevent users 
from sending rogue management messages you can simply not grant them the 
{{manage}} permission.

> Add a configuration option to disable management messages processing
> 
>
> Key: ARTEMIS-605
> URL: https://issues.apache.org/jira/browse/ARTEMIS-605
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>
> According to the documentation, one can switch off the broker management via 
> JMX using {{jmx-management-enabled}}.
> I did not find a similar option to switch off the broker management via 
> messages. One can configure it a bit ({{management-address}} and 
> {{management-notification-address}}) but apparently not disable it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (AMQ-6301) Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon edited comment on AMQ-6301 at 7/1/16 1:23 PM:
-

I did some more digging into this today to see what we would need to do to drop 
spring-dm for our 5.14 release.  I think we need a couple of new versions.  
First, xbean-spring needs a new release that supports spring 4.x.  There is an 
open ticket here: https://issues.apache.org/jira/browse/XBEAN-287

Second, looks like Camel 2.18 is going to drop the spring-dm dependency from 
spring-camel.  So I think we will need to wait for that version of Camel  to be 
released to drop spring-dm because camel-spring 2.17 has a dependency on Spring 
3.x for spring-dm support.  In version 2.18 spring-dm support has been 
separated out so camel-spring will work with spring 4.x.



was (Author: christopher.l.shannon):
I did some more digging into this today to see what we would need to do to drop 
spring-dm for our 5.14 release.  I think we need a couple of new versions.  
First, xbean-spring needs a new release that supports spring 4.x.  There is an 
open ticket here: https://issues.apache.org/jira/browse/XBEAN-287

Second, looks like Camel 2.18 is going to drop the spring-dm dependency from 
spring-camel.  So I think we will need to wait for that version of Camel  to be 
released to drop spring-dm because spring-camel 2.17 has a dependency on Spring 
3.x for spring-dm support.  In version 2.18 spring-dm support has been 
separated out so spring-camel will work with spring 4.x.


> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> 
>
> Key: AMQ-6301
> URL: https://issues.apache.org/jira/browse/AMQ-6301
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.13.0
>Reporter: Seth Leger
>  Labels: patch
>
> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> In commit 3a6d67e8f95320bea91b7c7106173c9b34773bc5, a test was fixed in issue 
> AMQ-4727 by reusing the spring-dm OsgiBundleXmlApplicationContext class 
> inside the ActiveMQServiceFactory managed service factory.
> To satisfy the import packages for activemq-osgi, the 'spring-dm' Karaf 
> feature was added to the main 'activemq-client' feature.
> This is problematic because loading the 'spring-dm' Karaf feature enables the 
> Spring DM deployer. This deployer is unnecessary in environments that rely on 
> Blueprint or CDI wiring and it may unexpectedly activate Spring DM bundles in 
> those environments. Because spring-dm was compiled against older versions of 
> Spring 3.0 and 3.1, it can also cause older versions of Spring features to be 
> loaded into the container.
> To avoid using the ‘spring-dm’ Karaf feature to provide the classes, I 
> propose embedding the spring-dm bundles inside activemq-osgi. Since they are 
> only used as library code to provide the BundleContext when parsing the 
> BrokerService context, they can be embedded safely without any dependency 
> issues.
> This is the root cause of the following issue:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-unable-to-start-bundle-activemq-osgi-5-13-0-td4044640.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-607) Interceptors don't work with non core protocols

2016-07-01 Thread Jiri Danek (JIRA)

Jiri Danek created ARTEMIS-607:
--

 Summary: Interceptors don't work with non core protocols
 Key: ARTEMIS-607
 URL: https://issues.apache.org/jira/browse/ARTEMIS-607
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.3.0
Reporter: Jiri Danek
Priority: Critical


I followed the {{examples/features/standard/interceptor}} example and built my 
own class that implements the Interceptor interface. I made it print a message 
every time it is triggered. That way I know this happens. I configured the 
broker and made the interceptor work for messages coming over the core protocol.

I then tried sending AMQP messages with 
{{qpid-proton/examples/python/simple_send.py}} and MQTT messages with 
https://github.com/iwanbk/nyamuk v0.2.0 and neither message triggered the 
interceptor.

I encountered this issue when trying to answer 
http://stackoverflow.com/questions/38101899/intercepting-mqtt-messages-in-artemis



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-408) Version 1.2.0 information is incorrect in Jira

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram updated ARTEMIS-408:
---
Issue Type: Bug  (was: Improvement)

> Version 1.2.0 information is incorrect in Jira
> --
>
> Key: ARTEMIS-408
> URL: https://issues.apache.org/jira/browse/ARTEMIS-408
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
>
> Looking at the [Road Map information in 
> Jira|https://issues.apache.org/jira/browse/ARTEMIS/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel]
>  we see that, for version 1.2.0:
>  - 2 out of the 43 issues have not been resolved yet
>  - it is not released yet
> Jira versions should reflect what has been released.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARTEMIS-607) Interceptors don't work with non core protocols

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram resolved ARTEMIS-607.

Resolution: Not A Bug

This is not a bug, per se. Interceptors have to be implemented for each 
protocol since interceptors intercept implementation-specific packets. The 
"interceptor" example shipped with Artemis contains an interceptor which 
intercepts org.apache.activemq.artemis.core.protocol.core.Packet objects. These 
are clearly part of the core protocol so you shouldn't expect to intercept them 
from clients using other protocols.

I recommend you open a feature request for the protocols for which you need 
interceptor support.

FWIW, this was recently discussed on the user-list as it relates to MQTT 
already.

> Interceptors don't work with non core protocols
> ---
>
> Key: ARTEMIS-607
> URL: https://issues.apache.org/jira/browse/ARTEMIS-607
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Danek
>Priority: Critical
>
> I followed the {{examples/features/standard/interceptor}} example and built 
> my own class that implements the Interceptor interface. I made it print a 
> message every time it is triggered. That way I know this happens. I 
> configured the broker and made the interceptor work for messages coming over 
> the core protocol.
> I then tried sending AMQP messages with 
> {{qpid-proton/examples/python/simple_send.py}} and MQTT messages with 
> https://github.com/iwanbk/nyamuk v0.2.0 and neither message triggered the 
> interceptor.
> I encountered this issue when trying to answer 
> http://stackoverflow.com/questions/38101899/intercepting-mqtt-messages-in-artemis



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (ARTEMIS-607) Implement support for Interceptors with the MQTT protocol

2016-07-01 Thread Jiri Danek (JIRA)


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

Jiri Danek reopened ARTEMIS-607:


> Implement support for Interceptors with the MQTT protocol
> -
>
> Key: ARTEMIS-607
> URL: https://issues.apache.org/jira/browse/ARTEMIS-607
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Danek
>
> Intercepting MQTT messages is not yet supported, only core protocol messages 
> can be intercepted. I would like to request a feature for MQTT interceptor 
> support.
> This feature was recently requested on the users@ mailing list 
> http://activemq.2283324.n4.nabble.com/Interceptor-for-MQTT-td4713408.html
> I encountered this issue when trying to answer 
> http://stackoverflow.com/questions/38101899/intercepting-mqtt-messages-in-artemis



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6301) Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

2016-07-01 Thread Christopher L. Shannon (JIRA)


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

Christopher L. Shannon commented on AMQ-6301:
-

Right, I think just Camel 2.17 requires camel-spring.

For 5.14.0, I think the correct thing is to drop spring-dm and maybe just 
support Camel 2.18+ for OSGi environments. It sounds like Camel 2.18 is on 
track for a August/September release.

As far as 5.13.x, embedding Spring dm may end up being the way to go to get 
Camel 2.16 to work properly (or even backing out that patch as Gary pointed out)

> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> 
>
> Key: AMQ-6301
> URL: https://issues.apache.org/jira/browse/AMQ-6301
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.13.0
>Reporter: Seth Leger
>  Labels: patch
>
> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> In commit 3a6d67e8f95320bea91b7c7106173c9b34773bc5, a test was fixed in issue 
> AMQ-4727 by reusing the spring-dm OsgiBundleXmlApplicationContext class 
> inside the ActiveMQServiceFactory managed service factory.
> To satisfy the import packages for activemq-osgi, the 'spring-dm' Karaf 
> feature was added to the main 'activemq-client' feature.
> This is problematic because loading the 'spring-dm' Karaf feature enables the 
> Spring DM deployer. This deployer is unnecessary in environments that rely on 
> Blueprint or CDI wiring and it may unexpectedly activate Spring DM bundles in 
> those environments. Because spring-dm was compiled against older versions of 
> Spring 3.0 and 3.1, it can also cause older versions of Spring features to be 
> loaded into the container.
> To avoid using the ‘spring-dm’ Karaf feature to provide the classes, I 
> propose embedding the spring-dm bundles inside activemq-osgi. Since they are 
> only used as library code to provide the BundleContext when parsing the 
> BrokerService context, they can be embedded safely without any dependency 
> issues.
> This is the root cause of the following issue:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-unable-to-start-bundle-activemq-osgi-5-13-0-td4044640.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-602) Unable to Add REST support

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-602:


Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/613
  
I sorted the dependency issue out, and I also ran the PR check on my local 
machine since the Apache CI seems to be flaky right now. It passed.


> Unable to Add REST support
> --
>
> Key: ARTEMIS-602
> URL: https://issues.apache.org/jira/browse/ARTEMIS-602
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Ding Jinqiang
>Assignee: Justin Bertram
>
> According to http://activemq.apache.org/artemis/docs/1.3.0/rest.html
> And 
> {quote}
>  org.apache.activemq.rest
>  activemq-rest
>  1.0.0.Final
> {quote}
> this does not exist in maven central, how can I build the war and deploy it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-572) Upgrade Jetty

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram reassigned ARTEMIS-572:
--

Assignee: Justin Bertram

> Upgrade Jetty
> -
>
> Key: ARTEMIS-572
> URL: https://issues.apache.org/jira/browse/ARTEMIS-572
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> The latest sources use the one year old Jetty 9.2.11.v20150529.
> The latest Jetty is a few weeks old only: v20160517.
> So Artemis should at least upgrade to 9.2.17.v20160517.
> However, for Java 8 users, it is probably better to use 9.3.9.v20160517.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-608) Document how to add user-provided classes to Broker class path

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram updated ARTEMIS-608:
---
Affects Version/s: (was: 1.4.0)

> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Danek
>  Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}} 
> directory **in the broker instance directory** and jar files in the lib 
> directory are put on the class path. To provide my own Interceptor or 
> something, it should be built into a jar and (together with all depending 
> jars) dropped into the instance's lib directory, so it can be found by the 
> broker.
> This deserves to be written up in the documentation. I believe that the only 
> place this is described (the part about the instance's lib at least) is 
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be 
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find 
> {{docs/user-manual/en/intercepting-operations.md}} and 
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the 
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You 
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ 
> Artemis distribution.{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-598) Incorrect message id in NativeLogger.java

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram updated ARTEMIS-598:
---
Affects Version/s: 1.3.0

> Incorrect message id in NativeLogger.java
> -
>
> Key: ARTEMIS-598
> URL: https://issues.apache.org/jira/browse/ARTEMIS-598
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> All the message ids are 6 digits long except in 
> {{artemis-native/src/main/java/org/apache/activemq/artemis/jlibaio/NativeLogger.java}}
>  where the code contains:
> {code}
> /**
>  * Logger Code 14
>  *
>  * each message id must be 6 digits long starting with 14, the 3rd digit 
> donates the level so
>  *
>  * INF0  1
>  * WARN  2
>  * DEBUG 3
>  * ERROR 4
>  * TRACE 5
>  * FATAL 6
>  *
>  * so an INFO message would be 1000 to 6000
>  */
> {code}
> but also:
> {code}
>@Message(id = 1001, value = "You have a native library with a different 
> version than expected", format = Message.Format.MESSAGE_FORMAT)
> {code}
> So this message id seems to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6301) Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

2016-07-01 Thread Seth Leger (JIRA)


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

Seth Leger commented on AMQ-6301:
-

Thanks for clarifying, I wasn't aware that Camel 2.17 required camel-spring. I 
totally agree with everything here. I wish it was easier but it's tough to line 
up dependencies sometimes. :)

> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> 
>
> Key: AMQ-6301
> URL: https://issues.apache.org/jira/browse/AMQ-6301
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.13.0
>Reporter: Seth Leger
>  Labels: patch
>
> Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf
> In commit 3a6d67e8f95320bea91b7c7106173c9b34773bc5, a test was fixed in issue 
> AMQ-4727 by reusing the spring-dm OsgiBundleXmlApplicationContext class 
> inside the ActiveMQServiceFactory managed service factory.
> To satisfy the import packages for activemq-osgi, the 'spring-dm' Karaf 
> feature was added to the main 'activemq-client' feature.
> This is problematic because loading the 'spring-dm' Karaf feature enables the 
> Spring DM deployer. This deployer is unnecessary in environments that rely on 
> Blueprint or CDI wiring and it may unexpectedly activate Spring DM bundles in 
> those environments. Because spring-dm was compiled against older versions of 
> Spring 3.0 and 3.1, it can also cause older versions of Spring features to be 
> loaded into the container.
> To avoid using the ‘spring-dm’ Karaf feature to provide the classes, I 
> propose embedding the spring-dm bundles inside activemq-osgi. Since they are 
> only used as library code to provide the BundleContext when parsing the 
> BrokerService context, they can be embedded safely without any dependency 
> issues.
> This is the root cause of the following issue:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-unable-to-start-bundle-activemq-osgi-5-13-0-td4044640.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-598) Incorrect message id in NativeLogger.java

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-598:


GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/615

ARTEMIS-598 fix native logger code



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-598

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/615.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #615


commit 2a144bc4eec59390bc792bcba75992a7db4787b4
Author: jbertram 
Date:   2016-07-01T20:14:15Z

ARTEMIS-598 fix native logger code




> Incorrect message id in NativeLogger.java
> -
>
> Key: ARTEMIS-598
> URL: https://issues.apache.org/jira/browse/ARTEMIS-598
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> All the message ids are 6 digits long except in 
> {{artemis-native/src/main/java/org/apache/activemq/artemis/jlibaio/NativeLogger.java}}
>  where the code contains:
> {code}
> /**
>  * Logger Code 14
>  *
>  * each message id must be 6 digits long starting with 14, the 3rd digit 
> donates the level so
>  *
>  * INF0  1
>  * WARN  2
>  * DEBUG 3
>  * ERROR 4
>  * TRACE 5
>  * FATAL 6
>  *
>  * so an INFO message would be 1000 to 6000
>  */
> {code}
> but also:
> {code}
>@Message(id = 1001, value = "You have a native library with a different 
> version than expected", format = Message.Format.MESSAGE_FORMAT)
> {code}
> So this message id seems to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-598) Incorrect message id in NativeLogger.java

2016-07-01 Thread Justin Bertram (JIRA)


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

Justin Bertram reassigned ARTEMIS-598:
--

Assignee: Justin Bertram

> Incorrect message id in NativeLogger.java
> -
>
> Key: ARTEMIS-598
> URL: https://issues.apache.org/jira/browse/ARTEMIS-598
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> All the message ids are 6 digits long except in 
> {{artemis-native/src/main/java/org/apache/activemq/artemis/jlibaio/NativeLogger.java}}
>  where the code contains:
> {code}
> /**
>  * Logger Code 14
>  *
>  * each message id must be 6 digits long starting with 14, the 3rd digit 
> donates the level so
>  *
>  * INF0  1
>  * WARN  2
>  * DEBUG 3
>  * ERROR 4
>  * TRACE 5
>  * FATAL 6
>  *
>  * so an INFO message would be 1000 to 6000
>  */
> {code}
> but also:
> {code}
>@Message(id = 1001, value = "You have a native library with a different 
> version than expected", format = Message.Format.MESSAGE_FORMAT)
> {code}
> So this message id seems to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-608) Document how to add user-provided classes to Broker class path

2016-07-01 Thread Jiri Danek (JIRA)


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

Jiri Danek updated ARTEMIS-608:
---
Affects Version/s: 1.4.0

> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: Broker
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Jiri Danek
>  Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}} 
> directory **in the broker instance directory** and jar files in the lib 
> directory are put on the class path. To provide my own Interceptor or 
> something, it should be built into a jar and (together with all depending 
> jars) dropped into the instance's lib directory, so it can be found by the 
> broker.
> This deserves to be written up in the documentation. I believe that the only 
> place this is described (the part about the instance's lib at least) is 
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be 
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find 
> {{docs/user-manual/en/intercepting-operations.md}} and 
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the 
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You 
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ 
> Artemis distribution.{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-608) Document how to add user-provided classes to Broker class path

2016-07-01 Thread Jiri Danek (JIRA)

Jiri Danek created ARTEMIS-608:
--

 Summary: Document how to add user-provided classes to Broker class 
path
 Key: ARTEMIS-608
 URL: https://issues.apache.org/jira/browse/ARTEMIS-608
 Project: ActiveMQ Artemis
  Issue Type: Task
  Components: Broker
Affects Versions: 1.3.0
Reporter: Jiri Danek


Broker reads the {{lib}} directory in the broker home directory and a {{lib}} 
directory **in the broker instance directory** and jar files in the lib 
directory are put on the class path. To provide my own Interceptor or 
something, it should be built into a jar and (together with all depending jars) 
dropped into the instance's lib directory, so it can be found by the broker.

This deserves to be written up in the documentation. I believe that the only 
place this is described (the part about the instance's lib at least) is 
http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.

Appropriate place for this explanation might be be 
{{docs/user-manual/en/using-server.md}}

There are few references to it, I managed to find 
{{docs/user-manual/en/intercepting-operations.md}} and 
{{docs/user-manual/en/persistence.md}} which say

{quote}The interceptors classes (and their dependencies) must be added to the 
server classpath to be properly instantiated and called.{quote}

{quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You 
can do this by dropping the relevant jars in the lib folder of the ActiveMQ 
Artemis distribution.{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure

2016-07-01 Thread Jiri Danek (JIRA)

Jiri Danek created ARTEMIS-609:
--

 Summary: Documentation for Interceptors is wrong regarding 
broker.xml file structure
 Key: ARTEMIS-609
 URL: https://issues.apache.org/jira/browse/ARTEMIS-609
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Jiri Danek


Documentation suggests that the {{}} element is 
a direct children of the {{}} element. In fact, it must be 
children of the {{}} element, the way it is done in 
{{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.

This issue is present in the following files

* {{docs/user-manual/en/intercepting-operations.md}}
* {{examples/features/standard/interceptor/readme.html}}
* {{examples/features/standard/interceptor-client/readme.html}}

I worry that these obsolete configuration fragments are remnants of some past 
change in the {{broker.xml}} file structure and that there could be more to be 
found.

One more thing. The last two files in my list have completely the same content. 
Is that really intentional?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-602) Unable to Add REST support

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-602:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/613#discussion_r69366570
  
--- Diff: examples/features/standard/rest/dup-send/README.txt ---
@@ -1,5 +1,5 @@
 System Requirements:
-You will need JDK 1.6 and Maven to run this example.  This example has 
been tested with Maven 2.2.1.  It may or may not work 
+You will need JDK 1.8 and Maven to run this example.  This example has 
been tested with Maven 3.3.3.  It may or may not work
--- End diff --

1.7 ?


> Unable to Add REST support
> --
>
> Key: ARTEMIS-602
> URL: https://issues.apache.org/jira/browse/ARTEMIS-602
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Ding Jinqiang
>Assignee: Justin Bertram
>
> According to http://activemq.apache.org/artemis/docs/1.3.0/rest.html
> And 
> {quote}
>  org.apache.activemq.rest
>  activemq-rest
>  1.0.0.Final
> {quote}
> this does not exist in maven central, how can I build the war and deploy it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-602) Unable to Add REST support

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-602:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/613#discussion_r69366595
  
--- Diff: examples/features/standard/rest/javascript-chat/README.txt ---
@@ -1,5 +1,5 @@
 System Requirements:
-You will need JDK 1.6, Maven, and a browser to run this example.  This 
example has been tested with Maven 2.2.1.  It may or may not work
--- End diff --

1.7?


> Unable to Add REST support
> --
>
> Key: ARTEMIS-602
> URL: https://issues.apache.org/jira/browse/ARTEMIS-602
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Ding Jinqiang
>Assignee: Justin Bertram
>
> According to http://activemq.apache.org/artemis/docs/1.3.0/rest.html
> And 
> {quote}
>  org.apache.activemq.rest
>  activemq-rest
>  1.0.0.Final
> {quote}
> this does not exist in maven central, how can I build the war and deploy it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-598) Incorrect message id in NativeLogger.java

2016-07-01 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on ARTEMIS-598:
-

Commit 2a144bc4eec59390bc792bcba75992a7db4787b4 in activemq-artemis's branch 
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2a144bc ]

ARTEMIS-598 fix native logger code


> Incorrect message id in NativeLogger.java
> -
>
> Key: ARTEMIS-598
> URL: https://issues.apache.org/jira/browse/ARTEMIS-598
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> All the message ids are 6 digits long except in 
> {{artemis-native/src/main/java/org/apache/activemq/artemis/jlibaio/NativeLogger.java}}
>  where the code contains:
> {code}
> /**
>  * Logger Code 14
>  *
>  * each message id must be 6 digits long starting with 14, the 3rd digit 
> donates the level so
>  *
>  * INF0  1
>  * WARN  2
>  * DEBUG 3
>  * ERROR 4
>  * TRACE 5
>  * FATAL 6
>  *
>  * so an INFO message would be 1000 to 6000
>  */
> {code}
> but also:
> {code}
>@Message(id = 1001, value = "You have a native library with a different 
> version than expected", format = Message.Format.MESSAGE_FORMAT)
> {code}
> So this message id seems to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-606) [Artemis Testsuite] JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails

2016-07-01 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on ARTEMIS-606:
-

Commit 45e4138fad2a3d3326576af92b99ced69a545e17 in activemq-artemis's branch 
refs/heads/master from [~eduda]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=45e4138 ]

ARTEMIS-606 JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM 
fails

Based on log it is clear that the connection was closed by Finalizer before the 
failure
was caused by the test itself. Since the connection variable is not referenced 
in the
code anymore, JVM concludes it can destroy the object. Especially IBM JDK does 
it very
fast.


> [Artemis Testsuite] 
> JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
> -
>
> Key: ARTEMIS-606
> URL: https://issues.apache.org/jira/browse/ARTEMIS-606
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: did not received the expected JMSException
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.doCloseConnectionsForUser(JMSServerControl2Test.java:1136)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.testCloseConnectionsForUserForInVM(JMSServerControl2Test.java:143)
> {code}
> {code}
> 11:49:34,359 INFO  [org.apache.activemq.artemis.core.server] #*#*# Starting 
> test: testCloseConnectionsForUserForInVM()...
> #test testCloseConnectionsForUserForInVM
> 11:49:34,394 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/journal,bindingsDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/bindings,largeMessagesDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/large-msg,pagingDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/page)
> 11:49:34,395 INFO  [org.apache.activemq.artemis.core.server] AMQ221012: Using 
> AIO Journal
> 11:49:34,397 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 11:49:34,399 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 11:49:34,400 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 11:49:34,401 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 11:49:34,403 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 11:49:34,404 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221007: 
> Server is now live
> 11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221001: 
> Apache ActiveMQ Artemis Message Broker version 1.1.0.jboss-SNAPSHOT 
> [nodeID=e915a1c8-3d47-11e6-a0a1-3172e2bd12af] 
> 11:49:34,606 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> trying to deploy queue jms.queue.97c12b14-0a31-4cb8-a1ad-5ba0217abb5f
> 11:49:34,650 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> trying to deploy queue jms.queue.66bdf106-b409-4e3c-b70b-d9918ea812c3
> 11:49:34,830 WARN  [org.apache.activemq.artemis.core.client] AMQ212037: 
> Connection failure has been detected: AMQ119108: connections for user 
> fakeUser closed by management [code=INTERNAL_ERROR]
> 11:49:34,830 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: 
> Client connection failed, clearing up resources for

[jira] [Commented] (ARTEMIS-598) Incorrect message id in NativeLogger.java

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-598:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/615


> Incorrect message id in NativeLogger.java
> -
>
> Key: ARTEMIS-598
> URL: https://issues.apache.org/jira/browse/ARTEMIS-598
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> All the message ids are 6 digits long except in 
> {{artemis-native/src/main/java/org/apache/activemq/artemis/jlibaio/NativeLogger.java}}
>  where the code contains:
> {code}
> /**
>  * Logger Code 14
>  *
>  * each message id must be 6 digits long starting with 14, the 3rd digit 
> donates the level so
>  *
>  * INF0  1
>  * WARN  2
>  * DEBUG 3
>  * ERROR 4
>  * TRACE 5
>  * FATAL 6
>  *
>  * so an INFO message would be 1000 to 6000
>  */
> {code}
> but also:
> {code}
>@Message(id = 1001, value = "You have a native library with a different 
> version than expected", format = Message.Format.MESSAGE_FORMAT)
> {code}
> So this message id seems to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-606) [Artemis Testsuite] JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-606:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/614


> [Artemis Testsuite] 
> JMSServerControl2Test#testCloseConsumerConnectionsForAddressForInVM fails
> -
>
> Key: ARTEMIS-606
> URL: https://issues.apache.org/jira/browse/ARTEMIS-606
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: did not received the expected JMSException
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.doCloseConnectionsForUser(JMSServerControl2Test.java:1136)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.server.management.JMSServerControl2Test.testCloseConnectionsForUserForInVM(JMSServerControl2Test.java:143)
> {code}
> {code}
> 11:49:34,359 INFO  [org.apache.activemq.artemis.core.server] #*#*# Starting 
> test: testCloseConnectionsForUserForInVM()...
> #test testCloseConnectionsForUserForInVM
> 11:49:34,394 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/journal,bindingsDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/bindings,largeMessagesDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/large-msg,pagingDirectory=/mnt/hudson_workspace/workspace/eap-70x-artemis-project-testsuite-rhel/NATIVES/true/jdk/ibm1.8/label/EAP-RHEL7/activemq-artemis/tests/integration-tests/./target/tmp/junit2245767348249816620/page)
> 11:49:34,395 INFO  [org.apache.activemq.artemis.core.server] AMQ221012: Using 
> AIO Journal
> 11:49:34,397 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 11:49:34,399 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 11:49:34,400 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 11:49:34,401 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 11:49:34,403 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 11:49:34,404 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221007: 
> Server is now live
> 11:49:34,506 INFO  [org.apache.activemq.artemis.core.server] AMQ221001: 
> Apache ActiveMQ Artemis Message Broker version 1.1.0.jboss-SNAPSHOT 
> [nodeID=e915a1c8-3d47-11e6-a0a1-3172e2bd12af] 
> 11:49:34,606 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> trying to deploy queue jms.queue.97c12b14-0a31-4cb8-a1ad-5ba0217abb5f
> 11:49:34,650 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> trying to deploy queue jms.queue.66bdf106-b409-4e3c-b70b-d9918ea812c3
> 11:49:34,830 WARN  [org.apache.activemq.artemis.core.client] AMQ212037: 
> Connection failure has been detected: AMQ119108: connections for user 
> fakeUser closed by management [code=INTERNAL_ERROR]
> 11:49:34,830 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: 
> Client connection failed, clearing up resources for session 
> e94bcd00-3d47-11e6-a0a1-3172e2bd12af
> 11:49:34,831 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: 
> Cleared up resources for session e94bcd00-3d47-11e6-a0a1-3172e2bd12af
> 11:49:34,846 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: 
> Client connection failed, clearing up resources for session 
> e94f9d91-3d47-11e6-a0a1-3172e2bd12af
> 11:49:34,848 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: 
> Cleared up resources for session

[jira] [Commented] (ARTEMIS-602) Unable to Add REST support

2016-07-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-602:


Github user jbertram commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/613#discussion_r69371083
  
--- Diff: examples/features/standard/rest/dup-send/README.txt ---
@@ -1,5 +1,5 @@
 System Requirements:
-You will need JDK 1.6 and Maven to run this example.  This example has 
been tested with Maven 2.2.1.  It may or may not work 
+You will need JDK 1.8 and Maven to run this example.  This example has 
been tested with Maven 3.3.3.  It may or may not work
--- End diff --

Are we stuck on 1.7?  It's been EOL for over a year now.


> Unable to Add REST support
> --
>
> Key: ARTEMIS-602
> URL: https://issues.apache.org/jira/browse/ARTEMIS-602
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Ding Jinqiang
>Assignee: Justin Bertram
>
> According to http://activemq.apache.org/artemis/docs/1.3.0/rest.html
> And 
> {quote}
>  org.apache.activemq.rest
>  activemq-rest
>  1.0.0.Final
> {quote}
> this does not exist in maven central, how can I build the war and deploy it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

38 matches

Mail list logo