Consumers should be able to unreceive messages they can't handle.
Simplify unreceive header structure.
Bump the required version of stomp, since 1.12.13 fixes unreceive behavior.
Bump stomp version (1.2.13->1.2.14; same behavior, fixes a versioning error).
Documentation of unreceive behavior.
Gem version 1.3.0
Merge pull request #2 from ismith/unreceive_behavior

Consumers should be able to unreceive messages they can't handle.
Force the configure block to be evaluated inside every instance of the worker class

This should make more dynamic configurations easier
Only exit the worker runloop if we're actually dead, not if we're reconnecting
Make sure signal handlers terminate all running instances of Stapfen::Worker cleanly

Fixes #4
Ensure all exit_cleanly methods get invoked for workers even if they raise exceptions

Fixes #5
Initial pass at providing a backend-agnostic Stapfen::Message class
Handle running as a JMS-based Stapfen::Worker
Merge pull request #6 from rtyler/master

Initial version of JMS support
Properly close both stomp and JMS connections

JMS::Connection#closed? doesn't exist, but we can safely just call #close
Allow converting Stapfen::Destination objects to JMS compatible qualified strings
Introduce a Stapfen::Client abstraction to unify the worker API code betwen STOMP and JMS

This requires more testing but thus far I've done some integration testing with an internal project
Add a few more specs for Stapfen::Client::JMS

Testing more parts of the #publish method might need to be left to integration
tests, otherwise we'll probably be stubbing out far too much of the "meat" of
the method
Minor cleanup based on @ismith's feedback
Update the READMe with the latest changes to support JMS