Defines a configuration retriever that read configuration from
and tracks changes periodically.
Data object representing the configuration of a configuration store. This object describes the configuration of a chunk of configuration that you retrieve. It specifies its type (type of configuration store), the format of the retrieved configuration chunk, and you can also configures the store if it needs configuration to retrieve the configuration chunk.
The composite future wraps a list of @see \io\vertx\jphp\core\Future futures, it is useful when several futures needs to be coordinated.
The handlers set for the coordinated futures are overridden by the handler of the composite future.
The execution context of a {@link io.vertx.core.Handler} execution.
When Vert.x provides an event to a handler or calls the start or stop methods of a \io\vertx\jphp\core\io.vertx.core.Verticle,
the execution is associated with a Context.
Usually a context is an *event-loop context* and is tied to a specific event loop thread. So executions for that context always occur on that exact same event loop thread.
In the case of worker verticles and running inline blocking code a worker context will be associated with the execution which will use a thread from the worker thread pool.
When a handler is set by a thread associated with a specific context, the Vert.x will guarantee that when that handler is executed, that execution will be associated with the same context.
If a handler is set by a thread not associated with a context (i.e. a non Vert.x thread). Then a new context will be created for that handler.
In other words, a context is propagated.
This means that when a verticle is deployed, any handlers it sets will be associated with the same context - the context of the verticle.
This means (in the case of a standard verticle) that the verticle code will always be executed with the exact same thread, so you don't have to worry about multi-threaded acccess to the verticle state and you can code your application as single threaded.
This class also allows arbitrary data to be @see \io\vertx\jphp\core\Context::put and @see \io\vertx\jphp\core\Context::get on the context so it can be shared easily amongst different handlers of, for example, a verticle instance.
This class also provides @see \io\vertx\jphp\core\Context::runOnContext which allows an action to be executed asynchronously using the same context.
This class represents a MultiMap of String keys to a List of String values.
It's useful in Vert.x to represent things in Vert.x like HTTP headers and HTTP parameters which allow multiple values for keys.
A timeout stream is triggered by a timer, the {@link io.vertx.core.Handler} will be call when the timer is fired, it can be once or several times depending on the nature of the timer related to this stream. The will be called after the timer handler has been called.
Pausing the timer inhibits the timer shots until the stream is resumed. Setting a null handler callback cancels the timer.
The entry point into the Vert.x Core API.
You use an instance of this class for functionality including:
Most functionality in Vert.x core is fairly low level.
To create an instance of this class you can use the static factory methods: @see \io\vertx\jphp\core\Vertx::vertx,
Most data is shuffled around inside Vert.x using buffers.
A buffer is a sequence of zero or more bytes that can read from or written to and which expands automatically as necessary to accommodate any bytes written to it. You can perhaps think of a buffer as smart byte array.
Please consult the documentation for more information on buffers.
Defines a command line argument. Unlike options, argument don't have names and are identified using an index. The first index is 0 (because we are in the computer world).
Interface defining a command-line interface (in other words a command such as 'run', 'ls'.
..). This interface is polyglot to ease reuse such as in Vert.x Shell.
A command line interface has a name, and defines a set of options and arguments. Options are key-value pair such
as -foo=bar or -flag. The supported formats depend on the used parser. Arguments are unlike
options raw values. Options are defined using
A received datagram packet (UDP) which contains the data and information about the sender of the data itself.
A datagram socket can be used to send @see \io\vertx\jphp\core\datagram\DatagramPacket's to remote datagram servers and receive @see \io\vertx\jphp\core\datagram\DatagramPackets .
Usually you use a datagram socket 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.
Please consult the documentation for more information on datagram sockets.
Configuration options for Vert.x hostname resolver. The resolver uses the local <i>hosts</i> file and performs DNS <i>A</i> and <i>AAAA</i> queries.
Encapsulates a message being delivered by Vert.x as well as providing control over the message delivery.
Used with event bus interceptors.
Delivery options are used to configure message delivery.
Delivery options allow to configure delivery timeout and message codec name, and to provide any headers that you wish to send with the message.
A Vert.x event-bus is a light-weight distributed messaging system which allows different parts of your application, or different applications and services to communicate with each in a loosely coupled way.
An event-bus supports publish-subscribe messaging, point-to-point messaging and request-response messaging.
Message delivery is best-effort and messages can be lost if failure of all or part of the event bus occurs.
Please refer to the documentation for more information on the event bus.
Represents a message that is received from the event bus in a handler.
Messages have a @see \io\vertx\jphp\core\eventbus\Message::body, which can be null, and also @see \io\vertx\jphp\core\eventbus\Message::headers, which can be empty.
If the message was sent specifying a reply handler, it can be replied to using @see \io\vertx\jphp\core\eventbus\Message::reply.
If you want to notify the sender that processing failed, then @see \io\vertx\jphp\core\eventbus\Message::fail can be called.
An event bus consumer object representing a stream of message to an @see \io\vertx\jphp\core\eventbus\EventBus address that can be read from.
The @see \io\vertx\jphp\core\eventbus\EventBus::consumer or @see \io\vertx\jphp\core\eventbus\EventBus::localConsumer creates a new consumer, the returned consumer is not yet registered against the event bus. Registration is effective after the @see \io\vertx\jphp\core\eventbus\MessageConsumer::handler method is invoked.
The consumer is unregistered from the event bus using the @see \io\vertx\jphp\core\eventbus\MessageConsumer::unregister method or by calling the
Represents a file on the file-system which can be read from, or written to asynchronously.
This class also implements @see \io\vertx\jphp\core\streams\ReadStream and
Contains a broad set of operations for manipulating files on the file system.
A (potential) blocking and non blocking version of each operation is provided.
The non blocking versions take a handler which is called when the operation completes or an error occurs.
The blocking versions are named xxxBlocking and return the results, or throw exceptions directly.
In many cases, depending on the operating system and file system some of the potentially blocking operations
can return quickly, which is why we provide them, but it's highly recommended that you test how long they take to
return in your particular application before using them on an event loop.
Please consult the documentation for more information on file system support.
HTTP2 settings, the settings is initialized with the default HTTP/2 values.<p>
The settings expose the parameters defined by the HTTP/2 specification, as well as extra settings for protocol extensions.
An asynchronous HTTP client.
It allows you to make requests to HTTP servers, and a single client can make requests to any server.
It also allows you to open WebSockets to servers.
The client can also pool HTTP connections.
For pooling to occur, keep-alive must be true on the @see \io\vertx\jphp\core\http\HttpClientOptions (default is true). In this case connections will be pooled and re-used if there are pending HTTP requests waiting to get a connection, otherwise they will be closed.
This gives the benefits of keep alive when the client is loaded but means we don't keep connections hanging around unnecessarily when there would be no benefits anyway.
The client also supports pipe-lining of requests. Pipe-lining means another request is sent on the same connection before the response from the preceding one has returned. Pipe-lining is not appropriate for all requests.
To enable pipe-lining, it must be enabled on the @see \io\vertx\jphp\core\http\HttpClientOptions (default is false).
When pipe-lining is enabled the connection will be automatically closed when all in-flight responses have returned and there are no outstanding pending requests to write.
The client is designed to be reused between requests.
Options describing how an @see \io\vertx\jphp\core\http\HttpClient will make connections.
Represents a client-side HTTP request.
Instances are created by an @see \io\vertx\jphp\core\http\HttpClient instance, via one of the methods corresponding to the specific HTTP methods, or the generic request methods. On creation the request will not have been written to the wire.
Once a request has been obtained, headers can be set on it, and data can be written to its body if required. Once you are ready to send the request, one of the @see \io\vertx\jphp\core\http\HttpClientRequest::end methods should be called.
Nothing is actually sent until the request has been internally assigned an HTTP connection.
The @see \io\vertx\jphp\core\http\HttpClient instance will return an instance of this class immediately, even if there are no HTTP connections available in the pool. Any requests sent before a connection is assigned will be queued internally and actually sent when an HTTP connection becomes available from the pool.
The headers of the request are queued for writing either when the @see \io\vertx\jphp\core\http\HttpClientRequest::end method is called, or, when the first part of the body is written, whichever occurs first.
This class supports both chunked and non-chunked HTTP.
It implements @see \io\vertx\jphp\core\streams\WriteStream so it can be used with
Represents a client-side HTTP response.
Vert.x provides you with one of these via the handler that was provided when creating the @see \io\vertx\jphp\core\http\HttpClientRequest or that was set on the @see \io\vertx\jphp\core\http\HttpClientRequest instance.
It implements @see \io\vertx\jphp\core\streams\ReadStream so it can be used with
Represents an HTTP connection.
HTTP/1.x connection provides an limited implementation, the following methods are implemented:
An HTTP and WebSockets server.
You receive HTTP requests by providing a @see \io\vertx\jphp\core\http\HttpServer::requestHandler. As requests arrive on the server the handler will be called with the requests.
You receive WebSockets by providing a @see \io\vertx\jphp\core\http\HttpServer::websocketHandler. As WebSocket connections arrive on the server, the WebSocket is passed to the handler.
Represents options used by an @see \io\vertx\jphp\core\http\HttpServer instance
Represents a server-side HTTP request.
Instances are created for each request and passed to the user via a handler.
Each instance of this class is associated with a corresponding @see \io\vertx\jphp\core\http\HttpServerResponse instance via
Represents a server-side HTTP response.
An instance of this is created and associated to every instance of
Options describing how an @see \io\vertx\jphp\core\http\HttpClient will make connect to make a request.
Represents a server side WebSocket.
Instances of this class are passed into a @see \io\vertx\jphp\core\http\HttpServer::websocketHandler or provided when a WebSocket handshake is manually @see \io\vertx\jphp\core\http\HttpServerRequest::upgradeed.
This class represents HTTP/2 stream priority defined in RFC 7540 clause 5.3
Base WebSocket implementation.
It implements both and so it can be used with
A WebSocket frame that represents either text or binary data.
A WebSocket message is composed of one or more WebSocket frames.
If there is a just a single frame in the message then a single text or binary frame should be created with final = true.
If there are more than one frames in the message, then the first frame should be a text or binary frame with final = false, followed by one or more continuation frames. The last continuation frame should have final = true.
Configures a @see \io\vertx\jphp\core\net\TCPSSLOptions to use the JDK ssl engine implementation.
Key or trust store options configuring private key and/or certificates based on Java Keystore files.
When used as a key store, it should point to a store containing a private key and its certificate. When used as a trust store, it should point to a store containing a list of trusted certificates.
The store can either be loaded by Vert.x from the filesystem:
HttpServerOptions options = HttpServerOptions.httpServerOptions();
options.setKeyStore(new JKSOptions().setPath("/mykeystore.jks").setPassword("foo"));
Or directly provided as a buffer:
Buffer store = vertx.fileSystem().readFileSync("/mykeystore.jks");
options.setKeyStore(new JKSOptions().setValue(store).setPassword("foo"));
A TCP client.
Multiple connections to different servers can be made using the same instance.
This client supports a configurable number of connection attempts and a configurable delay between attempts.
Represents a socket-like interface to a TCP connection on either the client or the server side.
Instances of this class are created on the client side by an @see \io\vertx\jphp\core\net\NetClient when a connection to a server is made, or on the server side by a @see \io\vertx\jphp\core\net\NetServer when a server accepts a connection.
It implements both and so it can be used with
Configures a @see \io\vertx\jphp\core\net\TCPSSLOptions to use OpenSsl.
Key store options configuring a list of private key and its certificate based on <i>Privacy-enhanced Electronic Email</i> (PEM) files.
A key file must contain a non encrypted private key in PKCS8 format wrapped in a PEM block, for example:
-----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDV6zPk5WqLwS0a ... K5xBhtm1AhdnZjx5KfW3BecE -----END PRIVATE KEY-----
Or contain a non encrypted private key in PKCS1 format wrapped in a PEM block, for example:
-----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAlO4gbHeFb/fmbUF/tOJfNPJumJUEqgzAzx8MBXv9Acyw9IRa ... zJ14Yd+t2fsLYVs2H0gxaA4DW6neCzgY3eKpSU0EBHUCFSXp/1+/ -----END RSA PRIVATE KEY-----
A certificate file must contain an X.509 certificate wrapped in a PEM block, for example:
-----BEGIN CERTIFICATE----- MIIDezCCAmOgAwIBAgIEZOI/3TANBgkqhkiG9w0BAQsFADBuMRAwDgYDVQQGEwdV ... +tmLSvYS39O2nqIzzAUfztkYnUlZmB0l/mKkVqbGJA== -----END CERTIFICATE-----Keys and certificates can either be loaded by Vert.x from the filesystem:
HttpServerOptions options = new HttpServerOptions();
options.setPemKeyCertOptions(new PemKeyCertOptions().setKeyPath("/mykey.pem").setCertPath("/mycert.pem"));
Or directly provided as a buffer:
Buffer key = vertx.fileSystem().readFileSync("/mykey.pem");
Buffer cert = vertx.fileSystem().readFileSync("/mycert.pem");
options.setPemKeyCertOptions(new PemKeyCertOptions().setKeyValue(key).setCertValue(cert));
Several key/certificate pairs can be used:
HttpServerOptions options = new HttpServerOptions();
options.setPemKeyCertOptions(new PemKeyCertOptions()
.addKeyPath("/mykey1.pem").addCertPath("/mycert1.pem")
.addKeyPath("/mykey2.pem").addCertPath("/mycert2.pem"));
Certificate Authority options configuring certificates based on <i>Privacy-enhanced Electronic Email</i> (PEM) files. The options is configured with a list of validating certificates.
Validating certificates must contain X.509 certificates wrapped in a PEM block:
-----BEGIN CERTIFICATE----- MIIDezCCAmOgAwIBAgIEVmLkwTANBgkqhkiG9w0BAQsFADBuMRAwDgYDVQQGEwdV ... z5+DuODBJUQst141Jmgq8bS543IU/5apcKQeGNxEyQ== -----END CERTIFICATE-----The certificates can either be loaded by Vert.x from the filesystem:
HttpServerOptions options = new HttpServerOptions();
options.setPemTrustOptions(new PemTrustOptions().addCertPath("/cert.pem"));
Or directly provided as a buffer:
Buffer cert = vertx.fileSystem().readFileSync("/cert.pem");
HttpServerOptions options = new HttpServerOptions();
options.setPemTrustOptions(new PemTrustOptions().addCertValue(cert));
Key or trust store options configuring private key and/or certificates based on PKCS#12 files.
When used as a key store, it should point to a store containing a private key and its certificate. When used as a trust store, it should point to a store containing a list of accepted certificates.
The store can either be loaded by Vert.x from the filesystem:
HttpServerOptions options = new HttpServerOptions();
options.setPfxKeyCertOptions(new PfxOptions().setPath("/mykeystore.p12").setPassword("foo"));
Or directly provided as a buffer:
Buffer store = vertx.fileSystem().readFileSync("/mykeystore.p12");
options.setPfxKeyCertOptions(new PfxOptions().setValue(store).setPassword("foo"));
A self-signed certificate helper for testing and development purposes.
While it helps for testing and development, it should never ever be used in production settings.
The address of a socket, an inet socket address or a domain socket address.
Use @see \io\vertx\jphp\core\net\SocketAddress::inetSocketAddress to create an inet socket address and @see \io\vertx\jphp\core\net\SocketAddress::domainSocketAddress to create a domain socket address
A parser class which allows to incrementally parse json elements and emit json parse events instead of parsing a json element fully. This parser is convenient for parsing large json structures.
The parser also parses concatenated json streams or line delimited json streams.
The parser can also parse entire object or array when it is convenient, for instance a very large array of small objects can be parsed efficiently by handling array start/end and object events.
Whenever the parser fails to parse or process the stream, the @see \io\vertx\jphp\core\parsetools\JsonParser::exceptionHandler is called with the cause of the failure and the current handling stops. After such event, the parser should not handle data anymore.
A helper class which allows you to easily parse protocols which are delimited by a sequence of bytes, or fixed size records.
Instances of this class take as input @see \io\vertx\jphp\core\buffer\Buffer instances containing raw bytes, and output records.
For example, if I had a simple ASCII text protocol delimited by '\n' and the input was the following:
buffer1:HELLO\nHOW ARE Y buffer2:OU?\nI AM buffer3: DOING OK buffer4:\nThen the output would be:
buffer1:HELLO buffer2:HOW ARE YOU? buffer3:I AM DOING OKInstances of this class can be changed between delimited mode and fixed size record mode on the fly as individual records are read, this allows you to parse protocols where, for example, the first 5 records might all be fixed size (of potentially different sizes), followed by some delimited records, followed by more fixed size records.
Instances of this class can't currently be used for protocols where the text is encoded with something other than a 1-1 byte-char mapping.
Please see the documentation for more information.
An asynchronous counter that can be used to across the cluster to maintain a consistent count.
Local maps can be used to share data safely in a single Vert.x instance.
By default the map allows immutable keys and values. Custom keys and values should implement \io\vertx\jphp\core\shareddata\io.vertx.core.shareddata.Shareable interface. The map returns their copies.
This ensures there is no shared access to mutable state from different threads (e.g. different event loops) in the Vert.x instance, and means you don't have to protect access to that state using synchronization or locks.
Since the version 3.4, this class extends the interface. However some methods are only accessible in Java.
Pumps data from a @see \io\vertx\jphp\core\streams\ReadStream to a @see \io\vertx\jphp\core\streams\WriteStream and performs flow control where necessary to prevent the write stream buffer from getting overfull.
Instances of this class read items from a @see \io\vertx\jphp\core\streams\ReadStream and write them to a @see \io\vertx\jphp\core\streams\WriteStream. If data can be read faster than it can be written this could result in the write queue of the @see \io\vertx\jphp\core\streams\WriteStream growing without bound, eventually causing it to exhaust all available RAM.
To prevent this, after each write, instances of this class check whether the write queue of the @see \io\vertx\jphp\core\streams\WriteStream is full, and if so, the @see \io\vertx\jphp\core\streams\ReadStream is paused, and a drainHandler is set on the
Represents a stream of items that can be read from.
Any class that implements this interface can be used by a @see \io\vertx\jphp\core\streams\Pump to pump data from it to a @see \io\vertx\jphp\core\streams\WriteStream.
handler.handler.0Chain several auth providers as if they were one. This is useful for cases where one want to authenticate across several providers, for example, database and fallback to passwd file.
Hashing Algorithm. A common interface to interact with any system provided algorithms.
Hashing Strategy manager.
This class will load system provided hashing strategies and algorithms.
Represents an authenticates User and contains operations to authorise the user.
Please consult the documentation for a detailed explanation.
A secure non blocking random number generator isolated to the current context. The PRNG is bound to the vert.x context and setup to close when the context shuts down.
When applicable, use of VertxContextPRNG rather than create new PRNG objects is helpful to keep the system entropy usage to the minimum avoiding potential blocking across the application.
The use of VertxContextPRNG is particularly appropriate when multiple handlers use random numbers.
Factory interface for creating @see \io\vertx\jphp\ext\auth\AuthProvider instances that use the Vert.x JDBC client.
By default the hashing strategy is SHA-512. If you're already running in production this is backwards compatible, however for new deployments or security upgrades it is recommended to use the PBKDF2 strategy as it is the current OWASP recommendation for password storage.
Factory interface for creating JWT based @see \io\vertx\jphp\ext\auth\AuthProvider instances.
Options related to creation of new tokens.
If any expiresInMinutes, audience, subject, issuer are not provided, there is no default. The jwt generated won't include those properties in the payload.
Generated JWTs will include an iat claim by default unless noTimestamp is specified.
Factory interface for creating OAuth2 based @see \io\vertx\jphp\ext\auth\AuthProvider instances.
Functional interface that allows users to implement custom RBAC verifiers for OAuth2/OpenId Connect.
Users are to implement the isAuthorized method to verify authorities. For provides that do not
export the permissions/roles in the token, this interface allows you to communicate with 3rd party services
such as graph APIs to collect the required data.
The contract is that once an authority is checked for a given user, it's value is cached during the execution of the request. If a user is stored to a persistent storage, or the token is introspected, the cache is cleared and a new call will be handled to the implementation.
Simplified factory to create an @see \io\vertx\jphp\ext\auth\oauth2\OAuth2Auth for Google.
Options used to perform blocking query that used to wait for a potential change using long polling.
Options used to placing a given service into "maintenance mode".
During maintenance mode, the service will be marked as unavailable and will not be present in DNS or API queries. Maintenance mode is persistent and will be automatically restored on agent restart.
Holds information describing which operations failed if the transaction was rolled back.
Watches are a way of specifying a view of data (e.g. list of nodes, KV pairs, health checks) which is monitored for updates. When an update is detected, an <code>Handler</code> with <code>AsyncResult</code> is invoked.
As an example, you could watch the status of health checks and notify when a check is critical.
A Vert.x Web handler on which you register health check procedure. It computes the outcome status (`UP` or `DOWN`)
. When the handler process a HTTP request, it computes the global outcome and build a HTTP response as follows:
SMTP mail client for Vert.x <p> A simple asynchronous API for sending mails from Vert.x applications
The shell server.<p/>
A shell server is associated with a collection of : the @see \io\vertx\jphp\ext\shell\ShellServer::registerTermServer method registers a term server. Term servers life cycle are managed by this server.
When a receives an incoming connection, a instance is created and associated with this connection.
The @see \io\vertx\jphp\ext\shell\ShellServer::createShell method can be used to create instance for testing purposes.
A Vert.x Shell command, it can be created from any language using the @see \io\vertx\jphp\ext\shell\command\CommandBuilder::command or from a Java class using @see \io\vertx\jphp\ext\shell\command\Command::create
The command process provides interaction with the process of the command provided by Vert.x Shell.
A job executed in a @see \io\vertx\jphp\ext\shell\system\JobController, grouping one or several process.<p/>
The job life cycle can be controlled with the @see \io\vertx\jphp\ext\shell\system\Job::run, @see \io\vertx\jphp\ext\shell\system\Job::resume and @see \io\vertx\jphp\ext\shell\system\Job::suspend and @see \io\vertx\jphp\ext\shell\system\Job::interrupt methods.
A pseudo terminal used for controlling a @see \io\vertx\jphp\ext\shell\term\Tty. This interface acts as a pseudo terminal master, @see \io\vertx\jphp\ext\shell\term\Pty::slave returns the assocated slave pseudo terminal.
Represents the results of a SQL query.
It contains a list for the column names of the results, and a list of JsonArray - one for each row of the
results.
A common asynchronous client interface for interacting with SQL compliant database
Represents the options one can use to customize the unwrapped connection/statement/resultset types
A ReadStream of Rows from the underlying RDBMS. This class follows the ReadStream semantics and will automatically close the underlying resources if all returned rows are returned. For cases where the results are ignored before the full processing of the returned rows is complete the close method **MUST** be called in order to release underlying resources.
The interface is minimal in order to support all SQL clients not just JDBC.
Structure passed to acknowledgement handler called when a <code>ACK</code> or <code>NACK</code> frame is received. The handler receives an instance of @see \io\vertx\jphp\ext\stomp\Acknowledgement with the subscription @see \io\vertx\jphp\ext\stomp\Frame and the impacted messages. The list of messages depends on the type of acknowledgment used by the subscription.
Subscriptions using the client mode receives all messages that were waiting for acknowledgment that were
sent before the acknowledged messages. The list also contains the acknowledged message. This is a cumulative
acknowledgement. Subscriptions using the client-individual mode receives a singleton list containing only
the acknowledged message.
Represents a STOMP destination.
Depending on the implementation, the message delivery is different. Queue are sending message to only one subscribers, while topics are broadcasting the message to all subscribers.
Implementations must be thread-safe.
Represents a STOMP frame. STOMP frames are structured as follows. It starts by a <code>command</code>, followed by a set of headers. Then the frame may have a body and is finished by a <code>0</code> byte. This class represents this structure and provide access to the different parts.
This class is NOT thread-safe.
Utility methods to build common @see \io\vertx\jphp\ext\stomp\Frames. It defines a non-STOMP frame (<code>PING</code>) that is used for heartbeats. When such frame is written on the wire it is just the <code>0</code> byte.
This class is thread-safe.
Structure passed to server handler when receiving a frame. It provides a reference on the received @see \io\vertx\jphp\ext\stomp\Frame but also on the @see \io\vertx\jphp\ext\stomp\StompServerConnection.
Once a connection to the STOMP server has been made, client receives a @see \io\vertx\jphp\ext\stomp\StompClientConnection, that let send and receive STOMP frames.
Options used to configure a STOMP client. As a STOMP client wraps a Net client, you can also configure the underlying NET client.
Defines a STOMP server. STOMP servers delegates to a @see \io\vertx\jphp\ext\stomp\StompServerHandler that let customize the behavior of the server. By default, it uses a handler compliant with the STOMP specification, but let you change anything.
Class representing a connection between a STOMP client a the server. It keeps a references on the client socket, so let write to this socket.
STOMP server handler implements the behavior of the STOMP server when a specific event occurs. For instance, if let customize the behavior when specific STOMP frames arrives or when a connection is closed. This class has been designed to let you customize the server behavior. The default implementation is compliant with the STOMP specification. In this default implementation, not acknowledge frames are dropped.
A completion object that emits completion notifications either <i>succeeded</i> or <i>failed</i>.
This object provides callback-ability for the end of a test suite, the completion <i>succeeds</i> when all tests pass otherwise it fails.
The test context is used for performing test assertions and manage the completion of the test. This context is provided by <i>vertx-unit</i> as argument of the test case.
Test execution options:
timeout in milliseconds, the default value is 2 minutes useEventLooptrue always runs with an event loopfalse never runs with an event loopnull uses an event loop if there is one (provided by @see \io\vertx\jphp\core\Vertx::currentContext)
otherwise run withoutreporters is an array of reporter configurationsA named suite of test cases that are executed altogether. The suite suite is created with the @see \io\vertx\jphp\ext\unit\TestSuite::create and the returned suite contains initially no tests.<p/>
The suite can declare a callback before the suite with @see \io\vertx\jphp\ext\unit\TestSuite::before or after the suite with @see \io\vertx\jphp\ext\unit\TestSuite::after.
The suite can declare a callback before each test with @see \io\vertx\jphp\ext\unit\TestSuite::beforeEach or after each test with @see \io\vertx\jphp\ext\unit\TestSuite::afterEach.
Each test case of the suite is declared by calling the @see \io\vertx\jphp\ext\unit\TestSuite::test method.
A failure provides the details of a failure that happened during the execution of a test case.<p/>
The failure can be:
Represents an HTTP Cookie.
All cookies must have a name and a value and can optionally have other fields set such as path, domain, etc.
(Derived from io.netty.handler.codec.http.Cookie)
A parsed language header.
Delivers a more direct access to the individual elements of the header it represents
A container with the request's headers that are meaningful enough to be parsed Contains: <ul> <li>Accept -> MIME header, parameters and sortable</li> <li>Accept-Charset -> Parameters and sortable</li> <li>Accept-Encoding -> Parameters and sortable</li> <li>Accept-Language -> Parameters and sortable</li> <li>Content-Type -> MIME header and parameters</li> </ul>
A route is a holder for a set of criteria which determine whether an HTTP request or failure should be routed to a handler.
A router receives request from an @see \io\vertx\jphp\core\http\HttpServer and routes it to the first matching
Represents the context for the handling of a request in Vert.x-Web.
A new instance is created for each HTTP request that is received in the of the router.
The same instance is passed to any matching request or failure handlers during the routing of the request or failure.
The context provides access to the and and allows you to maintain arbitrary data that lives for the lifetime of the context. Contexts are discarded once they have been routed to the handler for the request.
The context also provides access to the @see \io\vertx\jphp\ext\web\Session, cookies and body for the request, given the correct handlers in the application.
Represents a browser session.
Sessions persist between HTTP requests for a single browser session. They are deleted when the browser is closed, or they time-out. Session cookies are used to maintain sessions using a secure UUID.
Sessions can be used to maintain data for a browser session, e.g. a shopping basket.
The context must have first been routed to a @see \io\vertx\jphp\ext\web\handler\SessionHandler for sessions to be available.
Base interface for HTTP request validation with API specification
Interface for OpenAPI3RouterFactory. <br/> To add an handler, use @see \io\vertx\jphp\ext\web\api\contract\openapi3\OpenAPI3RouterFactory::addHandlerByOperationId<br/> Usage example: <pre> <code>OpenAPI3RouterFactory.create(vertx, "src/resources/spec.yaml", asyncResult -> { if (!asyncResult.succeeded()) { // IO failure or spec invalid</code> else { OpenAPI3RouterFactory routerFactory = asyncResult.result(); routerFactory.addHandlerByOperationId("operation_id", routingContext -> { // Do something }, routingContext -> { // Do something with failure handler }); Router router = routerFactory.getRouter(); } }); } </pre> <br/> Handlers are loaded in this order:<br/> <ol> <li>Body handler (Customizable with </li> <li>Custom global handlers configurable with </li> <li>Global security handlers defined in upper spec level</li> <li>Operation specific security handlers</li> <li>Generated validation handler</li> <li>User handlers or "Not implemented" handler</li> </ol>
Interface that define methods for deserialization of array and objects
This interface is used to add custom <b>synchronous</b> functions inside validation process. You can add it in
An interface for add HTTP Request validation. This class can validate parameters inside query, path, headers an body (watch below) <br/> You can assign multiple body type at the same time(for example a JSON schema together with a XML schema). This interface support: <ul> <li>application/x-www-form-urlencoded</li> <li>multipart/form-data</li> <li>application/xml</li> <li>application/json</li> </ul> Also you can add a form parameter for validation without care about content type of your request. For form parameters this interface support both "multipart/form-data" and "application/x-www-form-urlencoded" <br/> This interface allow extra parameters in the request, so it doesn't care if in a request there's a parameter without a specified validation rule <br/> If a parameter is flagged as an array, it will be validated also if the size of array is 1 element
Interface for declaration of method for validate a specific parameter type.<br/> If you want to implement your own type validator, you need only to implement
An HTTP response.
The usual HTTP response attributes are available:
The body of the response is returned by @see \io\vertx\jphp\ext\web\client\HttpResponse::body decoded as the format specified by the @see \io\vertx\jphp\ext\web\codec\BodyCodec that built the response.
Keep in mind that using this HttpResponse impose to fully buffer the response body and should be used for payload
that can fit in memory.
An asynchronous HTTP / HTTP/2 client called <code>WebClient</code>.
The web client makes easy to do HTTP request/response interactions with a web server, and provides advanced features like:
The web client does not deprecate the , it is actually based on it and therefore inherits
its configuration and great features like pooling. The HttpClient should be used when fine grained control over the HTTP
requests/response is necessary.
Converts a @see \io\vertx\jphp\ext\web\client\predicate\ResponsePredicateResult to a <code>Throwable</code> describing the error.
Base interface for auth handlers.
An auth handler allows your application to provide authentication/authorization support.
Auth handler requires a @see \io\vertx\jphp\ext\web\handler\SessionHandler to be on the routing chain before it.
A handler which gathers the entire request body and sets it on the .
It also handles HTTP file uploads and can be used to limit body sizes.
A handler which decodes cookies from the request, makes them available in the and writes them back in the response.
A handler which implements server side http://www.w3.org/TR/cors/[CORS] support for Vert.x-Web.
This handler adds a CSRF token to requests which mutate state. In order change the state a (XSRF-TOKEN) cookie is set with a unique token, that is expected to be sent back in a (X-XSRF-TOKEN) header.
The behavior is to check the request body header and cookie for validity.
This Handler requires session support, thus should be added somewhere below Session and Body handlers.
A handler that serves favicons.
If no file system path is specified it will attempt to serve a resource called `favicon.ico` from the classpath.
Handler that handles login from a form on a custom login page.
Used in conjunction with the @see \io\vertx\jphp\ext\web\handler\RedirectAuthHandler.
An auth handler that provides OAuth2 Authentication support. This handler is suitable for AuthCode flows.
An auth handler that's used to handle auth by redirecting user to a custom login page.
A handler which sets the response content type automatically according to the best <code>Accept</code> header match.
The header is set only if:
Handler which adds a header `x-response-time` in the response of matching requests containing the time taken in ms to process the request.
A handler that maintains a @see \io\vertx\jphp\ext\web\Session for each browser session.
It looks up the session for each request based on a session cookie which contains a session ID. It stores the session when the response is ended in the session store.
The session is available on the routing context with .
The session handler requires a @see \io\vertx\jphp\ext\web\handler\CookieHandler to be on the routing chain before it.
A handler which renders responses using a template engine and where the template name is selected from the URI path.
Handler that will timeout requests if the response has not been written after a certain time.
Timeout requests will be ended with an HTTP status code 503.
This handler should be used if you want to store the User object in the Session so it's available between different requests, without you having re-authenticate each time.
It requires that the session handler is already present on previous matching routes.
It requires an Auth provider so, if the user is deserialized from a clustered session it knows which Auth provider to associate the session with.
Represents an event that occurs on the event bus bridge.
Please consult the documentation for a full explanation.
A session store which stores sessions in a distributed map so they are available across the cluster.
Vert.x Kafka consumer.
You receive Kafka records by providing a @see \io\vertx\jphp\kafka\client\consumer\KafkaConsumer::handler. As messages arrive the handler will be called with the records.
The @see \io\vertx\jphp\kafka\client\consumer\KafkaConsumer::pause and @see \io\vertx\jphp\kafka\client\consumer\KafkaConsumer::resume provides global control over reading the records from the consumer.
The @see \io\vertx\jphp\kafka\client\consumer\KafkaConsumer::pause and @see \io\vertx\jphp\kafka\client\consumer\KafkaConsumer::resume provides finer grained control over reading records for specific Topic/Partition, these are Kafka's specific operations.
The metrics service mainly allows to return a snapshot of measured objects.<br/> This service is derived and adapted from <code>MetricsService</code> in the <i>vertx-dropwizard-metrics</i> module.
Vert.x micrometer configuration.
It is required to set either influxDbOptions, prometheusOptions or jmxMetricsOptions
(or, programmatically, micrometerRegistry) in order to actually report metrics.
Represents an MQTT endpoint for point-to-point communication with the remote MQTT client
An MQTT server <p> You can accept incoming MQTT connection requests providing a @see \io\vertx\jphp\mqtt\MqttServer::endpointHandler. As the requests arrive, the handler will be called with an instance of @see \io\vertx\jphp\mqtt\MqttEndpoint in order to manage the communication with the remote MQTT client.
This object controls the connection setting to the Redis Server. There is no need to specify most of the settings since it has built the following sensible defaults: <p> * `encoding`: `UTF-8` * `host`: `localhost` * `port`: 6379 * `tcpKeepAlive`: true * `tcpNoDelay`: true * `binary`: false <p> However there are two extra properties that have no defaults since they are optional: <p> * `auth` * `select` <p> The usage of this two extra properties is to setup required authentication and optionally the selection of the active database at connection time. If you define this extra properties on every connection to Redis server this client will perform the authentication handshake and database selection, however if you don't do this and call @see \io\vertx\jphp\redis\RedisClient::auth yourself in case of connection failure the client will not be able to perform the correct authentication handshake.
Describes a `service`. The record is the only piece of information shared between consumer and provider. It should contains enough metadata to let consumer find the service they want.
Service Discovery main entry point.
The service discovery is an infrastructure that let you publish and find `services`. A `service` is a discoverable functionality. It can be qualified by its type, metadata, and location. So a `service` can be a database, a service proxy, a HTTP endpoint. It does not have to be a vert.x entity, but can be anything. Each service is described by a @see \io\vertx\jphp\servicediscovery\Record.
The service discovery implements the interactions defined in the service-oriented computing. And to some extend, also provides the dynamic service-oriented computing interaction. So, application can react to arrival and departure of services.
A service provider can:
* publish a service record * un-publish a published record * update the status of a published service (down, out of service...)
A service consumer can:
* lookup for services * bind to a selected service (it gets a @see \io\vertx\jphp\servicediscovery\ServiceReference) and use it * release the service once the consumer is done with it * listen for arrival, departure and modification of services.
Consumer would 1) lookup for service record matching their need, 2) retrieve the @see \io\vertx\jphp\servicediscovery\ServiceReference that give access to the service, 3) get a service object to access the service, 4) release the service object once done.
A state above, the central piece of information shared by the providers and consumers are @see \io\vertx\jphp\servicediscovery\Record.
Providers and consumers must create their own @see \io\vertx\jphp\servicediscovery\ServiceDiscovery instance. These instances are collaborating in background (distributed structure) to keep the set of services in sync.
Once a consumer has chosen a service, it builds a @see \io\vertx\jphp\servicediscovery\ServiceReference managing the binding with the chosen service provider.
The reference lets the consumer: * access the service (via a proxy or a client) with the @see \io\vertx\jphp\servicediscovery\ServiceReference::get method * release the reference - so the binding between the consumer and the provider is removed
The service exporter allows integrate other discovery technologies with the Vert.x service discovery. It maps entries from another technology to a and maps to a publication in this other technology. The exporter is one side of a service discovery bridge.
for event bus services (service proxies).
Consumers receive a service proxy to use the service.
for HTTP endpoint (REST api).
Consumers receive a HTTP client configured with the host and port of the endpoint.
Represents the location of a HTTP endpoint. This object (its json representation) will be used as "location" in a service record.