I'm trying to use Proteus in a Clojure project, but I'm having trouble triggering the tool that generates 'services' per my proto definitions. I started with the build file found at https://proteus-java.readthedocs.io/en/latest/#getting-started but haven't been able to gradle generateProto.

Here's my build.gradle:

plugins {
    id 'com.google.protobuf' version '0.8.7'
    id 'java'
}

sourceCompatibility = 1.8

dependencies {
    compile "io.rsocket.rpc:rsocket-rpc-core:$rsocketRpcVersion"
    compile "com.google.protobuf:protobuf-java:$protobufVersion"
    compile "com.google.protobuf:protoc:$protobufVersion"
}

sourceSets {
    main {
        proto { srcDir 'resources/proto' }
    }

    test {
        proto { srcDir 'resources/proto' }
    }
}

protobuf {
    protoc {
        artifact = "com.google.protobuf:protoc:$protobufVersion"
    }
    plugins {
        proteus {
            artifact = 'io.netifi.proteus:proteus-java:1.5.4'
        }
    }
    generateProtoTasks {
        all()*.plugins {
            proteus {}
        }
    }
}

repositories {
  jcenter()
  maven {
    url 'https://dl.bintray.com/netifi/netifi-oss'
  }
}

Any tips on how to make this thing work?

Issue

Currently, using proteus-java with Spring Boot causes compilation issues. Spring Boot is pulling in an incompatible version of Guava which overrides the version imported by proteus-java.

Solution

We need to shade guava in the proteus-java jars.

Current Workaround

You can force the dependency resolution in Gradle using the following, but it is ugly and not cool of us to ask people to add that to each of their spring-based proteus projects.

configurations.all {
    resolutionStrategy {
        dependencySubstitution {
            substitute module('com.google.guava:guava') with module('com.google.guava:guava:22.0')
        }
    }
}

Per these cards, broker_info.proto needs some additions in order to provide destination IP addresses and additional broker address info to the console.

https://netifi.atlassian.net/browse/PROT-196 https://netifi.atlassian.net/browse/PROT-285

https://github.com/netifi-proteus/proteus-java/blob/2d287cf0333fe2b175f448f1655fbe8e086fcd2b/frames/src/main/java/io/netifi/proteus/frames/AuthenticationResponseFlyweight.java#L35

Isn't the sequence ID written as part of the header? Is this redundant or is there something I missed on the authentication response frame such that it needs it twice?

With Proteus client of version 1.5.3 the client won't reconnect to the Proteus server after connection failure, for example when the server was restarted.

It does work well for clients from version 1.5.2, even more: In a machine with multiple clients, both 1.5.2 and 1.5.3, only the clients of 1.5.2 had survived Proteus server restart (restarted more than 2 times to verify) .

In addition, the ability to use Proteus in integration tests (bringing up a test container with Proteus server) was also damaged. Again, when going back to 1.5.2 it works fine.

The ability to reconnect to the server is critical for applications in production, making it impossible to use the new 1.5.3 version.

Hi!

Currently, the generated code contains code for the metrics & tracing, even if it's optional. Would be great to have an option to disable them at the code generation phase.

Thanks!