INT-4317: JMS: dynamic deliverMode and timeToLive

[artembilan]

JIRA: https://jira.spring.io/browse/INT-4317

• Add deliveryModeExpression and timeToLiveExpression properties
  to the JmsSendingMessageHandler and expose them in the Java DSL and
  XML components
• Add setMapInboundDeliveryMode() and setMapInboundExpiration()
boolean properties (default false) to the DefaultJmsHeaderMapper
  for transferring JMSDeliveryMode and JMSExpiration into appropriate
  JmsHeaders.DELIVERY_MODE and JmsHeaders.EXPIRATION headers
• Upgrade to latest Kotlin and AssertK

[garyrussell]

Just a couple of comments/questions.

[garyrussell]

61 is out already.

[garyrussell]

Why is the exclusion no longer needed?

[artembilan]

According my Gradle report the old version is remapped pretty well:

+--- com.willowtreeapps.assertk:assertk-jvm:0.12
|    +--- com.willowtreeapps.assertk:assertk-common:0.12
|    |    +--- org.jetbrains.kotlin:kotlin-stdlib-common:1.2.50 -> 1.2.61
|    |    \--- com.willowtreeapps.opentest4k:opentest4k-common:1.1.0
|    |         \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.2.41 -> 1.2.61
|    +--- org.jetbrains.kotlin:kotlin-stdlib:1.2.50 -> 1.2.61
|    |    +--- org.jetbrains.kotlin:kotlin-stdlib-common:1.2.61
|    |    \--- org.jetbrains:annotations:13.0
|    +--- org.jetbrains.kotlin:kotlin-reflect:1.2.50 -> 1.2.61
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.2.61 (*)
|    \--- com.willowtreeapps.opentest4k:opentest4k-jvm:1.1.0
|         +--- com.willowtreeapps.opentest4k:opentest4k-common:1.1.0 (*)
|         +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.2.41 -> 1.2.61
|         |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.2.61 (*)
|         |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.61
|         |         \--- org.jetbrains.kotlin:kotlin-stdlib:1.2.61 (*)
|         \--- org.opentest4j:opentest4j:1.1.0
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.2.61 (*)

And there is no any issues during running tests against that latest AssertK.

[garyrussell]

I wonder if it would be better to have one ThreadLocal with a container?

[artembilan]

Not sure what is your concern: we have a container there and it is a ThreadLocalMap:

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

So, essentially with your suggestion we are going to have only a single entry in this map, but we would create that extra container anyway.
And at the same time we would lose a flexibility when we deal only with one property. For example a setPriority() is used from the AbstractJmsChannel, too.

So, what am I missing staying with the standard Java approach?

Thanks

[garyrussell]

Well, we now have 3 ThreadLocals.

I was just suggesting one ThreadLocal<SomeContainer> and one DynamicJmsTemplateProperties.clear() method.

On the other hand, we'd create/remove a new Object for each send, so I suppose the current is better (since the ThreadLocalMap is retained).

So, OK, LGTM.

[artembilan]

Huh? No, there is a single map-per-thread: ThreadLocalMap map = getMap(t);. As I said: essentially it is the same container as you suggest.

[garyrussell]

I didn't mean to say there wasn't a map per thread. My main point was we could replace

DynamicJmsTemplateProperties.clearPriority();
DynamicJmsTemplateProperties.clearDeliveryMode();
DynamicJmsTemplateProperties.clearTimeToLive();

with just one DynamicJmsTemplateProperties.clear() method.

But, as I said, I am ok with this.