Vert.x clojure language module API documentation

vertx.buffer

Functions for operating on Vert.x Buffers.
A Buffer represents a sequence of zero or more bytes that can be
written to or read from, and which expands as necessary to
accommodate any bytes written to it.

append!, set! and as-buffer take several different types of data
that can be written to a buffer these types are referred to
collectively as "bufferable", and are:

* Buffer
* Byte
* byte[]
* Double
* BigDecimal (coerced to a Double)
* Ratio (coerced to a Double)
* Float
* Integer
* Long
* BigInt (coerced to a Long)
* Short
* String

Public variables and functions:

vertx.core

Vert.x core functionality.

Public variables and functions:

vertx.embed

Functions for running Vert.x embedded.

Public variables and functions:

vertx.eventbus

Functions for operating on the Vert.x EventBus and its Messages.
The event bus implements publish / subscribe, point to point
messaging and request-response messaging.

Messages sent over the event bus are represented by instances of
the org.vertx.java.core.eventbus.Message class.

For publish / subscribe, messages can be published to an address
using publish function. An address is a simple String instance.

Handlers are registered against an address. There can be multiple
handlers registered against each address, and a particular handler
can be registered against multiple addresses. The event bus will
route a sent message to all handlers which are registered against
that address.

For point to point messaging, messages can be sent to an address
using the send function. The messages will be delivered to a single
handler, if one is registered on that address. If more than one
handler is registered on the same address, Vert.x will choose one
and deliver the message to that. Vert.x will aim to fairly
distribute messages in a round-robin way, but does not guarantee
strict round-robin under all circumstances.

All messages sent over the bus are transient. On event of failure
of all or part of the event bus messages may be lost. Applications
should be coded to cope with lost messages, e.g. by resending them,
and making application services idempotent.

The order of messages received by any specific handler from a
specific sender should match the order of messages sent from that
sender.

When sending a message, a reply handler can be provided. If so, it
will be called when the reply from the receiver has been
received. Reply messages can also be replied to, etc, ad infinitum.

Different event bus instances can be clustered together over a
network, to give a single logical event bus.

If handlers are registered from an event loop, they will be
executed using that same event loop. If they are registered from
outside an event loop (i.e. when using Vert.x embedded) then Vert.x
will assign an event loop to the handler and use it to deliver
messages to that handler.

Public variables and functions:

vertx.filesystem

Provides a broad set of functions for manipulating files. Wraps the
asynchronous methods from org.vertx.java.core.file.FileSystem.

Public variables and functions:

vertx.filesystem.sync

Provides a broad set of functions for manipulating files. Wraps the
synchronous methods from org.vertx.java.core.file.FileSystem.

Public variables and functions:

vertx.http

Provides a broad set of functions for creating HTTP servers and
clients, and handling requests.

Public variables and functions:

vertx.http.route

Functions for operating on Vertx.x RouteMatcher.
RouteMatchers allows you to do route requests based on the HTTP
verb and the request URI, in a manner similar Sinatra or Express.

RouteMatchers also let you extract parameters from the request URI
either a via simple pattern or using regular expressions for more
complex matches. Any parameters extracted will be added to the
requests parameters which will be available to you in your request
handler.

Public variables and functions:

vertx.http.sockjs

This is an implementation of the server side part of https://github.com/sockjs.

SockJS enables browsers to communicate with the server using a
simple WebSocket-like api for sending and receiving messages. Under
the bonnet SockJS chooses to use one of several protocols depending
on browser capabilities and what appears to be working across the
network.

Available protocols include:

* WebSockets
* xhr-polling
* xhr-streaming
* json-polling
* event-source
* html-file

This means it should just work irrespective of what browser
is being used, and whether there are nasty things like proxies and
load balancers between the client and the server.

For more detailed information on SockJS, see their website.

On the server side, you interact using instances of SockJSSocket -
this allows you to send data to the client or receive data via
vertx.stream/on-data.

You can register multiple applications with the same SockJSServer,
each using different path prefixes, each application will have its
own handler, and configuration.

Public variables and functions:

vertx.http.websocket

Provides a set of functions for using http websockets.

Public variables and functions:

vertx.logging

Functions for logging to the Vert.x logging subsystem.

Public variables and functions:

vertx.net

Provides a broad set of functions for creating TCP servers and
clients.

Public variables and functions:

vertx.repl

Functions for managing nREPLs within a Vert.x container.

Public variables and functions:

vertx.shareddata

Functions for sharing data between verticles on the same Vert.x instance.

Public variables and functions:

vertx.stream

Functions that operate on Vert.x ReadStreams and WriteStreams.

Public variables and functions: