vertx-lang-scala-docs_2.12 3.4.2 API < Back
 

# Packages

-  package root
  Definition Classes
    root
-  package io
  Definition Classes
    root
-  package vertx
  Definition Classes
    io
-  package scala
  Definition Classes
    vertx
-  package amqpbridge
  Definition Classes
    scala
-  package circuitbreaker
  Definition Classes
    scala
-  package core
  Definition Classes
    scala
-  package cli
-  package datagram
-  package dns
-  package eventbus
-  package file
-  package http
-  package metrics
-  package net
-  package parsetools
-  package shareddata
-  package streams
- CompositeFuture
- Context
- DeploymentOptions
- Future
- MultiMap
- TimeoutStream
- Vertx
- VertxOptions
- WorkerExecutor
-  package ext
  Definition Classes
    scala
-  package kafka
  Definition Classes
    scala
-  package mqtt
  Definition Classes
    scala
-  package rabbitmq
  Definition Classes
    scala
-  package redis
  Definition Classes
    scala

p

io.vertx.scala

# core 

#### package core

 
Ordering

1. Alphabetic

Visibility

1. Public
2. All

### Type Members

1.  class CompositeFuture extends Future[CompositeFuture]

   The composite future wraps a list of io.vertx.scala.core.Future, it is useful when several futures needs to be coordinated.

   The composite future wraps a list of io.vertx.scala.core.Future, 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.

2.  class Context extends AnyRef

   The execution context of a scala-function execution.

   The execution context of a scala-function execution.

   When Vert.x provides an event to a handler or calls the start or stop methods of a io.vertx.lang.scala.ScalaVerticle, 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 io.vertx.scala.core.Context#put and io.vertx.scala.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 io.vertx.scala.core.Context#runOnContext which allows an action to be executed asynchronously using the same context.

3.  class DeploymentOptions extends AnyRef

   Options for configuring a verticle deployment.

4.  class Future [T] extends AnyRef

   Represents the result of an action that may, or may not, have occurred yet.

5.  class MultiMap extends AnyRef

   This class represents a MultiMap of String keys to a List of String values.

   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.

6.  class TimeoutStream extends ReadStream[Long]

   A timeout stream is triggered by a timer, the scala-function 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.

   A timeout stream is triggered by a timer, the scala-function 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.

7.  class Vertx extends Measured

   The entry point into the Vert.x Core API.

   The entry point into the Vert.x Core API.

   You use an instance of this class for functionality including:

   - Creating TCP clients and servers
   - Creating HTTP clients and servers
   - Creating DNS clients
   - Creating Datagram sockets
   - Setting and cancelling periodic and one-shot timers
   - Getting a reference to the event bus API
   - Getting a reference to the file system API
   - Getting a reference to the shared data API
   - Deploying and undeploying verticles

   Most functionality in Vert.x core is fairly low level.

   To create an instance of this class you can use the static factory methods: io.vertx.scala.core.Vertx#vertx, io.vertx.scala.core.Vertx#vertx and io.vertx.scala.core.Vertx#clusteredVertxFuture.

   Please see the user manual for more detailed usage information.

8.  class VertxOptions extends AnyRef

   Instances of this class are used to configure io.vertx.scala.core.Vertx instances.

9.  class WorkerExecutor extends Measured

   An executor for executing blocking code in Vert.x .

   An executor for executing blocking code in Vert.x .

   It provides the same `executeBlocking` operation than io.vertx.scala.core.Context and io.vertx.scala.core.Vertx but on a separate worker pool.

### Value Members

1.  object CompositeFuture
2.  object Context
3.  object DeploymentOptions
4.  object Future
5.  object MultiMap
6.  object TimeoutStream
7.  object Vertx
8.  object VertxOptions
9.  object WorkerExecutor

### Ungrouped