Ensure Java 1.6 compatibility
Domain classes, stream/module deployments

Introduced Module and Stream domain classes. The stream/module
deployment flow is as follows:

1. Stream request is written to:

/xd/streams/<stream-name>

2. Admin "prepares" the stream by expanding out
the expected deployment:

/xd/streams/<stream-name>/source/<module-name>
                         /processor/
                         /sink/

3. Admin issues deployment request to specific
container:

/xd/deployments/<module-name>

4. The container server writes an ephemeral node
under the module that it just deployed under
the /xd/streams/.../<module-name> node.

5. This is an indication to the admin server
that the module was deployed.
Missing break

https://github.com/markfisher/xdzk/pull/12/files#r10166830
Updates from Mark's review

https://github.com/markfisher/xdzk/pull/12
Introduced ApplicationContext/Boot

Servers are started with dedicated *Application
classes that create an application context and
start their respective servers via Boot.

https://github.com/markfisher/xdzk/issues/13
Updates from review, fixed tests

Changes that came from the PR review:
https://github.com/markfisher/xdzk/pull/17

Modified the AdminContainerObserverTest to work with the new
application context (as opposed to a static singleton).
Added simple Stream deployment manifest

Stream deployment manifest provides hints for module deployments
within a stream.

Using format /xd/deployments/<container>/stream.moduleType.moduleName
Fixed command line arg issue with test

After the migration to Boot we changed the command line arg
format to --zk=host:port. These changes were not reflected
in the tests which caused them to fall back to the default
ZK host:port. I noticed this as a problem after taking down
the ZK server and seeing the tests fail.
Initial module redeployment on container departure

https://github.com/markfisher/xdzk/issues/19
Leader Admin handles container departure

The Curator cache for containers (/xd/containers) is now
initialized and torn down as part of the leadership election
lifecycle. This mirrors the pattern used for the stream cache
(/xd/streams).
Support for module labels

Added support for module labels. Module labels are used in
the stream and deployment paths to ensure unique naming.
Initial container group support

Containers can indicate group membership via command line
argument. Deployments can be targeted to groups. Right now
all group members are sent module deployments; next step
is to allow a configurable number of group members to
take a deployment.
Handle number of containers within a group

The "all" group concept has been removed. Instead a count of
0 should be specified to indicate that all members of a group
should receive a module deployment. If there is no group
specified, then all containers will receive the deployment.
Leader deploys modules to new containers

When a new container arrives the leader will deploy any
modules to it that need to be deployed.

ContainerListener was moved from ContainerServer to its
own top level class.
Updates from PR 20

Various updates from https://github.com/markfisher/xdzk/pull/20/.

Removed onChildAdded from INITIALIZED event in ContainerServer
as this was causing repeated deployments for new containers.

DeploymentManifestMatcher now enforces 1 module per container.

Added unit tests for DeploymentManifestMatcher.

Renamed Paths.createPath to Paths.build
Introduced stream deletion

A stream can be deleted (and its modules undeployed) by
removing it from ZK. Each individual container will respond
by undeploying the modules it has for the given stream.

https://github.com/markfisher/xdzk/issues/15
Fixed path issue

The leader admin was creating a path of /xd/xd/admin. This
was caused by the unnecessary prepending of /xd to the
Paths.ADMIN string. It turns out that the leadership
API requires that paths contain a leading / whereas
the rest of the Curator client API will add a leading
/ when a namespace is declared upon client construction.

Therefore, in order to be consistent across the board,
the leading / is always provided by Paths.build.
Container server tracks deployed modules

Container server is now tracking deployed modules.
Additionally it can track modules by label and type
(instead of name and type).
Introduced StreamsPaths object

StreamsPath is used for round trip creation/extraction of
/xd/streams path elements.
Using StreamsPath to construct/break down paths

Replace manual string manipulation with StreamsPath.