Add Artemis broker to Kura core

[ctron]

As discussed last week during the F2F meeting, Artemis should get added to the Kura core distribution for providing a local gateway broker.

[ctron]

It looks like Artemis requires at least the compact3 profile due to javax.management

[jreimann@jreimann org.eclipse.kura.broker.artemis.core]$ jdeps -P  target/org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar
org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar -> not found
org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar -> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/lib/rt.jar (compact3)
   org.eclipse.kura.broker.artemis.core (org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar)
      -> com.google.common.collect                          not found
      -> com.google.common.io                               not found
      -> java.io                                            compact1
      -> java.lang                                          compact1
      -> java.lang.management                               compact3
      -> java.net                                           compact1
      -> java.nio.charset                                   compact1
      -> java.nio.file                                      compact1
      -> java.nio.file.attribute                            compact1
      -> java.util                                          compact1
      -> javax.management                                   compact3
      -> org.apache.activemq.artemis.core.config            not found
      -> org.apache.activemq.artemis.core.config.impl       not found
      -> org.apache.activemq.artemis.core.deployers         not found
      -> org.apache.activemq.artemis.core.server            not found
      -> org.apache.activemq.artemis.jms.server.config.impl not found
      -> org.apache.activemq.artemis.spi.core.protocol      not found
      -> org.apache.activemq.artemis.spi.core.security      not found
      -> org.apache.activemq.artemis.spi.core.security.jaas not found
      -> org.eclipse.kura.broker.artemis.core.internal      org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar
      -> org.osgi.framework                                 not found
      -> org.slf4j                                          not found
   org.eclipse.kura.broker.artemis.core.internal (org.eclipse.kura.broker.artemis.core-1.0.0-SNAPSHOT.jar)
      -> com.google.common.collect                          not found
      -> java.lang                                          compact1
      -> java.util                                          compact1
      -> org.apache.activemq.artemis.spi.core.protocol      not found
      -> org.osgi.framework                                 not found
      -> org.osgi.util.tracker                              not found
      -> org.slf4j                                          not found

[kartben]

The management capabilities can simply be disabled at runtime, maybe? https://activemq.apache.org/artemis/docs/1.0.0/management.html#configuring-jmx - not sure it would be enough though as there seems to be many places where java.lang.management classes are used.

[ctron]

The functionality can be disabled and code will not be called. However the references in the class files will still remain.

[dejanb]

Unfortunately, we can't remove that dependency easily as the code is in the server bundle. But this can be a good improvement, so that in constrained environments we can turn jmx off and use amqp management instead.
Maybe an easier temporary solution is to declare dependency as optional in manifest and turn off the feature. I'll take a look at that

[cdealti]

@nicolatimeus can you please review?

[nicolatimeus]

I've performed a quick test on a Raspberry Pi 3, here is some feedback:

• the Simple mode based on MQTT seem to work, I was able to successfully connect the cloud service of the the device to the Artemis instance hosted by the device itself, basic publish-subscribe functionalities work.
  Just a minor issue: I needed to modify the build_equinox_distrib.xml file by adding the :startcommand to the org.eclipse.kura.broker.artemis.core and org.apache.activemq.artemis-mqtt-protocol bundles.
• the AMQP protocol bundle does not start due to a missing dependency:

osgi> bundles | grep amqp
org.apache.activemq.artemis-amqp-protocol_2.1.0 [106]
true
osgi> start 106
gogo: BundleException: Could not resolve module: org.apache.activemq.artemis-amqp-protocol [106]
  Unresolved requirement: Import-Package: org.apache.qpid.proton; version="[0.18.0,1.0.0)"

[cdealti]

@nicolatimeus can you please also check:

1. Secure (SSL) MQTT connection
2. MQTT over Websocket

[ctron]

@nicolatimeus What is the reason to start org.eclipse.kura.broker.artemis.core?

The AMQP part is a "known issue" ;-) we need to discuss is we want that and I would then start to work on CQs.

[nicolatimeus]

If org.eclipse.kura.broker.artemis.core is not explicitly started a NullPointerException is thrown when trying to startup the broker.
The exception is caused by this line, the problem is that if the bundle is not explicitly started it will end up in the RESOLVED state, and Bundle.getBundleContext() will return null.
According to the javadoc Bundle.getBundleContext() returns null if the bundle is not in the STARTING, ACTIVE, or STOPPING states.

[nicolatimeus]

• MQTT over Websocket works out of the box in Simple mode using non-secure connections, I've managed to connect both the CloudService of the device and an external javascript application using Paho. For the latter case I needed to change the MQTT address configuration property to 0.0.0.0, otherwise connections not originating from the device itself will not be accepted.

• Secure MQTT connections over SSL work as well but require some additional configuration, I've performed the following steps:

  • Create an external keystore containing a self-signed certificate located for example at /opt/keystore.jks
  • Copy-paste the broker.xml file used for the Simple mode into the Broker XML configuration property of the ActiveMQ Artemis Broker service and then create a test user assigned to the amq role.
  • Modify the acceptors section of the broker configuration file in this way:

  <acceptors>
     <acceptor name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT</acceptor>
     <acceptor name="mqtts">tcp://0.0.0.0:8883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;sslEnabled=true;keyStorePath=/opt/keystore.jks;keyStorePassword=password</acceptor>
  </acceptors>

  • Export the previously created self-singned certificate from the keystore in PEM format and add it to the Server SSL Certificate configuration section under Settings, and restart Kura.
  • Modify the CloudService configuration by entering the credentials of the user defined above and set the ssl.hostname.verification property to False.
  • The connection should now work

I still have to test Websocket over SSL

[ctron]

The exception is caused by this line, the problem is that if the bundle is not explicitly started it will end up in the RESOLVED state, and Bundle.getBundleContext() will return null.

Yes, because I did remove the lazy flag. Ok, so I don't think we need to auto-start it, but to re-add the lazy flag for the bundle.

[nicolatimeus]

Setting the lazy flag works as expected, let's go for it then.

[ctron]

I already did update the branch, currently testing it locally.

[nicolatimeus]

Websocket over SSL works as well with the same setup used for testing secure MQTT connections described above.
Connecting a Kura CloudService to the broker in this way should work after #1565 is merged.