Skip to content

Latest commit

 

History

History
275 lines (213 loc) · 12.1 KB

README.md

File metadata and controls

275 lines (213 loc) · 12.1 KB
Raw

Dapr SDK for Java

Build Status Discord codecov License: Apache-2.0 FOSSA Status Maven Central

This is the Dapr SDK for Java, including the following features:

  • PubSub
  • Service Invocation
  • Binding
  • State Store
  • Actors

Getting Started

Pre-Requisites

Importing Dapr's Java SDK

For a Maven project, add the following to your pom.xml file:

<project>
  ...
  <dependencies>
    ...
     <!-- Dapr's core SDK with all features, except Actors. -->
    <dependency>
      <groupId>io.dapr</groupId>
      <artifactId>dapr-sdk</artifactId>
      <version>1.5.0</version>
    </dependency>
    <!-- Dapr's SDK for Actors (optional). -->
    <dependency>
      <groupId>io.dapr</groupId>
      <artifactId>dapr-sdk-actors</artifactId>
      <version>1.5.0</version>
    </dependency>
    <!-- Dapr's SDK integration with SpringBoot (optional). -->
    <dependency>
      <groupId>io.dapr</groupId>
      <artifactId>dapr-sdk-springboot</artifactId>
      <version>1.5.0</version>
    </dependency>
    ...
  </dependencies>
  ...
</project>

For a Gradle project, add the following to your build.gradle file:

dependencies {
...
    // Dapr's core SDK with all features, except Actors.
    compile('io.dapr:dapr-sdk:1.5.0')
    // Dapr's SDK for Actors (optional).
    compile('io.dapr:dapr-sdk-actors:1.5.0')
    // Dapr's SDK integration with SpringBoot (optional).
    compile('io.dapr:dapr-sdk-springboot:1.5.0')
}

Running the examples

Clone this repository including the submodules:

git clone https://github.com/dapr/java-sdk.git

Then head over to build the Maven (Apache Maven version 3.x) project:

# make sure you are in the `java-sdk` directory.
mvn clean install

Try the following examples to learn more about Dapr's Java SDK:

API Documentation

Please, refer to our Javadoc website.

Reactor API

The Java SDK for Dapr is built using Project Reactor. It provides an asynchronous API for Java. When consuming a result is consumed synchronously, as in the examples referenced above, the block() method is used.

The code below does not make any API call, it simply returns the Mono publisher object. Nothing happens until the application subscribes or blocks on the result:

Mono<Void> result = daprClient.publishEvent("mytopic", "my message");

To start execution and receive the result object synchronously(void or Void becomes an empty result), use block(). The code below shows how to execute the call and consume an empty response:

Mono<Void> result = daprClient.publishEvent("mytopic", "my message");
result.block();

How to use a custom serializer

This SDK provides a basic serialization for request/response objects but also for state objects. Applications should provide their own serialization for production scenarios.

  1. Implement the DaprObjectSerializer interface. See this class as example.
  2. Use your serializer class in the following scenarios: 
    DaprClient client = (new DaprClientBuilder())
    .withObjectSerializer(new MyObjectSerializer()) // for request/response objects.
    .withStateSerializer(new MyStateSerializer()) // for state objects.
    .build();
    • When registering an Actor Type:
    ActorRuntime.getInstance().registerActor(
  DemoActorImpl.class,
  new MyObjectSerializer(), // for request/response objects.
  new MyStateSerializer()); // for state objects.
    • When building a new instance of ActorProxy to invoke an Actor instance, use the same serializer as when registering the Actor Type:
    try (ActorClient actorClient = new ActorClient()) {
  DemoActor actor = (new ActorProxyBuilder(DemoActor.class, actorClient))
      .withObjectSerializer(new MyObjectSerializer()) // for request/response objects.
      .build(new ActorId("100"));
}

Debug Java application or Dapr's Java SDK

In IntelliJ Community Edition, consider debugging in IntelliJ.

In Visual Studio Code, consider debugging in Visual Studio Code.

If you need to debug your Application, run Dapr sidecar separately and then start the application from your IDE (IntelliJ, for example). For Linux and MacOS:

dapr run --app-id testapp --app-port 3000 --dapr-http-port 3500 --dapr-grpc-port 5001

Note: confirm the correct port that the app will listen to and that the Dapr ports above are free, changing the ports if necessary.

When running your Java application from IDE, make sure the following environment variables are set, so the Java SDK knows how to connect to Dapr's sidecar:

DAPR_HTTP_PORT=3500
DAPR_GRPC_PORT=5001

Now you can go to your IDE (like Eclipse, for example) and debug your Java application, using port 3500 to call Dapr while also listening to port 3000 to expose Dapr's callback endpoint.

Exception handling

Most exceptions thrown from the SDK are instances of DaprException. DaprException extends from RuntimeException, making it compatible with Project Reactor. See example for more details.

Development

Update proto files

Change the properties below in pom.xml to point to the desired reference URL in Git. Avoid pointing to master branch since it can change over time and create unpredictable behavior in the build.

<project>
  ...
  <properties>
    ...
    <dapr.proto.url>https://raw.githubusercontent.com/dapr/dapr/v1.0.0/pkg/proto/dapr/dapr.proto</dapr.proto.url>
    <dapr.client.proto.url>https://raw.githubusercontent.com/dapr/dapr/v1.0.0/pkg/proto/daprclient/daprclient.proto</dapr.client.proto.url>
    ...
  </properties>
  ...
</project>

Running Integration Tests

Pre-Requisites for ITs

Along with the pre-requisites for SDK the following are needed.

Code

The code for the tests are present inside the project sdk-tests. This module alone can be imported as a separate project in IDEs. This project depends on the rest of the JARs built by the other modules in the repo like sdk, sdk-springboot etc.

As a starting point for running Integration Tests, first run mvn clean install from the root of the repo to build the JARs for the different modules except the sdk-tests module.

Run all the dependent services spun up during build

During normal CI build, docker compose is used to bring up services like MongoDB, Hashicorp Vault, Apache Zookeeper, Kafka etc.

Similarly, all of these need to be run for running the ITs either individually or as a whole.

Run the following commands from the root of the repo to start all the docker containers that the tests depend on.

docker-compose -f ./sdk-tests/deploy/local-test-kafka.yml up -d
docker-compose -f ./sdk-tests/deploy/local-test-mongo.yml up -d
docker-compose -f ./sdk-tests/deploy/local-test-vault.yml up -d

To stop the containers and services, run the following commands.

docker-compose -f ./sdk-tests/deploy/local-test-kafka.yml down
docker-compose -f ./sdk-tests/deploy/local-test-mongo.yml down
docker-compose -f ./sdk-tests/deploy/local-test-vault.yml down

Run all ITs from command line

From the java-sdk repo root, change to the sdk-tests directory and run the following command.

## with current directory as /java-sdk/sdk-tests/

mvn clean install

The above command runs all the integration tests present in the sdk-tests project.

Run Individual tests from IntelliJ

In IntelliJ, go to File > New > Project from Existing Sources.... Import the sdk-tests project.

Once the project has been imported, the individual tests can be run normally as any Unit Tests, from the IDE itself.

intellij-integration-test.

Sometimes when the sdk-tests project does not build correctly, try File > Invalidate Caches... and try restarting IntelliJ.

You should be able to set breakpoints and Debug the test directly from IntelliJ itself as seen from the above image.