Added JRuby support.
docker watcher: continue polling if a single host fails
docker watcher: follow log convention
Merge pull request #32 from Clever/docker-api-resiliency

docker watcher: continue polling if a single host fails
Merge pull request #27 from airbnb/dynamic-config

JRuby support WIP.
introduce .mailmap

Dedups git shortlog -sne
make the example config file valid json
don't use require relative in the example watcher
minor whitespace cleanup; remove require_relative
ignore jar file artifact
basic infrastructure for allowing watchers to stop cleanly

this is sufficient for the docker and dns watchers, which run in their
own loops
special stop handler for the zookeeper watcher

calling stop! should unsubscribe from pending events, but we handle this
manually anyway
ensure we explicitly stop all watchers in main thread
re-raise exceptions instead of `throw`ing 'em
Merge pull request #36 from airbnb/cleanup

Cleanup & Proper Exit Handling
bump version to v0.8.0
shared frontend stanzas in haproxy sections

Assuming that your underlying architecture makes no breaking assumptions,
there is no need to dedicate a port to each service: services which need to
be co-located on a single IP address can, for instance, share some sort of
app container and route based on host or path names.

While haproxy can route on host headers, synapse currently assumes a 1:1
frontend:backend ratio.  But what we want here is a single frontend mapping
to multiple backends based on acl rules.  So herein, a simple stab at it:
if there is a "shared_frontend" key in the root haproxy config, we create
a "shared-frontend" frontend, read in any configuration lines, and then as
we iterate over the services, pluck out any shared_frontend lines like so:

  { "haproxy": {
      "shared_frontend": [
        "bind 127.0.0.1:8081"
      ],
      "global": [
        "daemon",
        "stats socket /var/run/haproxy.sock"
      ],
      "defaults": [
        "log      global",
      ],
    },
    "services": {
      "service1": {
        "haproxy": {
          "server_options": "check inter 2s rise 3 fall 2",
          "backend": [
            "mode http"
          ],
          "shared_frontend": [
            "acl is_service1 hdr_dom(host) -i service1.lb",
            "use_backend service1 if is_service1"
          ]
        }
      },
      "service2": {
        "haproxy": {
          "server_options": "check inter 2s rise 3 fall 2",
          "backend": [
            "mode http"
          ],
          "shared_frontend": [
            "acl is_service2 hdr_dom(host) -i service2.lb",
            "use_backend service2 if is_service2"
          ]
        }
      }
    }
  }

...produces a FE/BE config like this:

  frontend service1
        bind localhost:8086
        default_backend service1

  backend service1
        mode http
        server host1_service1:8101_20d8a0f6 10.73.132.39:8101 check inter 2s rise 3 fall 2
        server host1_service1:8101_4f48153f 10.181.203.244:8101 check inter 2s rise 3 fall 2

  backend service2
        mode http
        server host1_service2:8101_6f0a9d02 10.60.12.9:8101 check inter 2s rise 3 fall 2
        server host2_service2:8101_f3518f4f 10.81.23.44:8101 check inter 2s rise 3 fall 2

  frontend shared-frontend
        bind 127.0.0.1:8081
        acl is_service1 hdr_dom(host) -i service1.lb
        use_backend service1 if is_service1
        acl is_service2 hdr_dom(host) -i service2.lb
        use_backend service2 if is_service2
add project.clj to build out an installable debian package
allow override of listening address

If, for instance, one wanted to have a pool of dedicated haproxy servers that
handled queries for other hosts, it would help to be able to listen on ports
other than localhost.

Default to the expected behavior.