On 02/13/2018 07:29 PM, Jeroen van Ooststroom wrote:
I added the wireFormat.allowNonSaslConnections=true to the AMQP
transport connector configuration which resolves the issue of the
JavaScript client not being able to connect anymore, but I still get
the same kind of BytesMessage at the
I added the wireFormat.allowNonSaslConnections=true to the AMQP
transport connector configuration which resolves the issue of the
JavaScript client not being able to connect anymore, but I still get the
same kind of BytesMessage at the Java-side as mentioned in the original
post with the added
On 02/13/2018 06:22 PM, Jeroen van Ooststroom wrote:
Thank you for your response.
When I upgrade to ActiveMQ 5.15.3 my simple JavaScript client isn't
able to connect to the AMQP connector anymore:
error on read: ProtocolError: SASL layer not enabled
Thank you for your response.
When I upgrade to ActiveMQ 5.15.3 my simple JavaScript client isn't able
to connect to the AMQP connector anymore:
error on read: ProtocolError: SASL layer not enabled
(buffer:0x41,0x4d,0x51,0x50,0x03,0x01,0x00,0x00)
I'm not familiar with this. Does this
This is great idea! I get so frustrated with these environment issues. +100
Some other advantages I could see we could implement if successful.
run a Linux build and a macOS build eg to check bits like kqueue and or other
os specific behaviours (aio fallback to nio)
look to use appveyor for a
On 02/13/2018 05:29 PM, Jeroen van Ooststroom wrote:
I have a simple test JavaScript (Node.js) client that connects to
ActiveMQ using AMQP and our Java client that connects to the same
ActiveMQ using OpenWire (JMS). When I send a message from the
JavaScript client (just a simple “Hello
I have a simple test JavaScript (Node.js) client that connects to
ActiveMQ using AMQP and our Java client that connects to the same
ActiveMQ using OpenWire (JMS). When I send a message from the JavaScript
client (just a simple “Hello World!”) it is received by the Java client
as a
Over the last several months I've noticed that the Jenkins-based builds
used to validate GitHub pull-requests for Artemis are failing at a
significant rate for illegitimate reasons (e.g. environmental issues,
timing out because they're too slow, etc.) or not being run at all. Even
as I type this
CVE-2017-15709 - Information Leak
Severity: Low
Vendor:
The Apache Software Foundation
Versions Affected:
Apache ActiveMQ 5.14.0 - 5.15.2
Description:
When using the OpenWire protocol it was found that certain system
details (such as the OS and kernel version) are exposed as plain text.
