The "system" STOMP session is established at startup and can be used
to send messages without a client session, e.g. to support broadcasting
from a REST/HTTP handler method.
MessageHolder holds the currently processed message in a ThreadLocal,
which allows PubSubMessageBuilder to automatically add a session id
to messages to be sent.
Rename to PubSubHeaderAccessor and StompHeaderAccessor
Move the renamed classes to support packages
Remove fromPayloadAndHeaders from MessageBuilder, just use
withPayload(..).copyHeaders(..) instead.
The use of an AtomicBoolean and no lock meant that it was possible
for a message to be queued and then never be flushed and sent to the
broker:
1. On t1, a message is received and isConnected is false. The message
will be queued.
2. On t2, CONNECTED is received from the broker. isConnected is set
to true, the queue is drained and the queued messages are forwarded
3. On t1, the message is added to the queue
To fix this, checking that isConnected is false (step 1 above) and the
queueing of a message (step 3 above) need to be performed as a unit
so that the flushing of the queued messages can't be interleaved. This
is achieved by synchronizing on a monitor and performing steps 1
and 3 and synchronizing on the same monitor while performing step 2.
The monitor is held while the messages are actually being forwarded
to the broker. An alternative would be to drain the queue into
a local variable, release the monitor, and then forward the messages.
The main advantage of this alternative is that the monitor is held for
less time. It also reduces the theoretical risk of deadlock by not
holding the monitor while making an alien call. The downside of the
alternative is that it may lead to messages being forwarded out of
order. For this reason the alternative approach was rejected.
When an annotated handler returns a Message from a @SubscribeEvent
or @MessageMapping method and it contains no destination in its
headers, use the received message's destination as the response
message's destination.
Without generics, extending AbstractPubSubChannelRegistry and using
a custom Message type requires some unpleasant casting and suppression
of warnings. By genericizing PubSubChannelRegistry and
AbstractPubSubChannelRegistry these problems can be avoided.
To improve compatibility between Spring's messaging classes and
Spring Integration, the type of Message that is created has been made
pluggable through the introduction of a factory abstraction;
MessageFactory.
By default a MessageFactory is provided that will create
org.springframework.messaging.GenericMessage instances, however this
can be replaced with an alternative implementation. For example,
Spring Integration can provide an implementation that creates
org.springframework.integration.message.GenericMessage instances.
This control over the type of Message that's created allows messages
to flow from Spring messaging code into Spring Integration code without
any need for conversion. In further support of this goal,
MessageChannel, MessageHandler, and SubscribableChannel have been
genericized to make the Message type that they deal with more
flexible.
org.springframework.web.stomp is now
org.springframework.web.messaging.stomp
Also classes in the ~.stomp.server and ~.stomp.adapter packages have
been renamed.
JOpt 4.4 has enumerable options, so this change can be made
if we upgrade. The only awkward thing is that JOpt allows
aliases for options, so we have to pick one to avoid double
counting. This implementation picks the last one in the list
which is the alphebtically last of the long options, if there
are any (e.g. "o1", "option1" returns "option1"). Most of the
time there will only be one or two aliases for each option so
it won't matter.
Issue: SPR-10579
The submitted pull requests for SPR-10572 did not build.
This commit fixes the MergePlugin to create from configurations rather
than the project. It also removes unnecessarily added code that was
commented out.
Issue: SPR-10572
Recently Spring framework build has been updated to use Gradle 1.6.
With the new version some of the Gradle APIs have been deprecated.
These deprecated APIs have been used by Spring build specific Gradle
plugins, which resulted in deprecation warnings in build output.
This patch changes Spring build specific Gradle plugins to use new
Gradle APIs instead of deprecated ones.
Even after this change build still produces warnings about Gradle
deprecated APIs being used. These come from Spring shared Gradle
plugins and other 3rd party Gradle plugins in use, like Gradle
Artifactory Plugin (GAP), which are still not updated to Gradle 1.6.
Related tickets for updating of these plugins to Gradle 1.6 are
GRADLE-53 and GAP-144, and once they get resolved Spring framework
build should further be updated.
Issue: SPR-10572
