Vert.x clojure language module API documentation
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
Vert.x core functionality.
Public variables and functions:
Provides a broad set of functions for UDP servers and clients. Usually you use a Datragram Client to send UDP over the wire. UDP is connection-less which means you are not connected to the remote peer in a persistent way. Because of this you have to supply the address and port of the remote peer when sending data. You can send data to ipv4 or ipv6 addresses, which also include multicast addresses.
Provides functions for asynchronous DNS operations.
Functions for running Vert.x embedded.
Functions for running Vert.x embedded with a platform manager.
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.
Provides a broad set of functions for manipulating files. Wraps the asynchronous methods from org.vertx.java.core.file.FileSystem.
Provides a broad set of functions for manipulating files. Wraps the synchronous methods from org.vertx.java.core.file.FileSystem.
Provides a broad set of functions for creating HTTP servers and clients, and handling requests.
Public variables and functions:
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.
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.
Provides a set of functions for using http websockets.
Functions for logging to the Vert.x logging subsystem.
Provides a broad set of functions for creating TCP servers and clients.
Functions for managing nREPLs within a Vert.x container.
Functions for sharing data between verticles on the same Vert.x instance.