Add a new disableAutoRequest method that disables all automatic requests while disableAutoInboundFlowControl maintains existing behavior.
The default behavior of requesting initial messages is applied even if disableAutoInboundFlowControl is called. ServerCalls disables all automatic flow control which is much more useful in case the user can't handle incoming messages until some time after the call has started. This change creates a new StartableListener that has an onStart method that is invoked when the call is started which makes initial requests if necessary.
See #6806
javax.annotation-api is licensed CDDL, which was not noticed when it was
introduced. Tomcat provides an Apache 2 version of the same annotation. Note
that this annotation is only used when compiling with Java 9+.
Unfortunately this may cause classpath collisions since there are _many_ copies
of this annotation on Maven Central; we wanted one canonical source and
javax.annotation-api seemed like that source. We hope this won't impact many
users since we have always suggested using it only for compilation. But it will
probably impact some users. However, we didn't create this mess, this seems to
be "standard practice" for J2EE, which this annotation is now part of, so we're
just impacted by it.
Fixes#6833
The target can be provided on the command line to avoid needing to recompile
the example just to change where the server is located. We use a target instead
of addresses as that is the approach we have wanted to encourage for a while
since it allows choosing alternative name resolvers.
We typically encourage injecting Channels, not ManagedChannels, which has the
added benefit of simplifying the example. Less indirection makes for a better
example.
Swapping to target string could be done to examples-tls and examples-gauth as
well, but it would be much more invasive to the tls example and the gauth
example would need proper testing after the change.
maven_install is strongly superior to previous forms of grabbing dependencies
from Maven as it computes the appropriate versions to use from the full
transitive dependencies of all libraries used by an application. It also has
much less boilerplate and includes dependencies with generated targets.
In the future we will drop the jvm_maven_import_external usages and require
maven_install, at which point we can swap to using the `@maven' repository and
no longer depend on compat_repositories.
Fixes#5359
* examples: use test certs for running example-tls
* fixed a typo
* update usage printout for trustCertCollectionFilePath is not optional
* Revert "update usage printout for trustCertCollectionFilePath is not optional"
This reverts commit 2dd6d87f64.
* put back the usage of using system default CA and put notes for it
* fixed cmd-line argument options
* examples: make tls example easier to run
* Make the ca cert able to be verified by the server cert in openssl
* Make the port number consistent in each example (easy to copy paste wrong one)
* use correct netty-tcnative
* address comments
This reverts commit ac52e27b2a.
See #5665. Right now it is not any more informative than the header
example, and it encourages some practices I'd rather avoid. It will get
re-added later with improvements.
io.grpc has fewer dependencies than io.grpc.internal. Moving it to a
separate artifact lets users use the API without bringing in the deps.
If the library has an optional dependency on grpc, that can be quite
convenient.
We now version-pin both grpc-api and grpc-core, since both contain
internal APIs.
I had to change a few tests in grpc-api to avoid FakeClock. Moving
FakeClock to grpc-api was difficult because it uses
io.grpc.internal.TimeProvider, which can't be moved since it is a
production class. Having grpc-api's tests depend on grpc-core's test
classes would be weird and cause a circular dependincy. Having
grpc-api's tests depend on grpc-core is likely possible, but weird and
fairly unnecessary at this point. So instead I rewrote the tests to
avoid FakeClock.
Fixes#1447
This mainly avoids protoc from 3.7.0 which has a dependency on libatomic. Most
of our systems have libatomic, so it mostly works, but the interop docker
container does not, so building fails. Version 3.7.1 was rebuilt to avoid
needing the libatomic shared library.
This has the added benefit that Bazel is now on the same version as Gradle, as
3.7.1 included fixes for Bazel.
* added android example running under strictmode to detect grpc clear text network transport
* renamed andriod strictmode example
* use OkHttpChannelBuilder's api to feed with user's own transport executor
* bump gradle and proto-plugin version to match that in master
* add README with a simple demo image
* Update README to use relative link to helloworld
This resolves#5523
While bumping `com.android.tools.build:gradle:3.1.2` to `3.3.0`, some other plugins/artifacts/maven repo/buildscripts have to be updated:
- gradle (wrapper) need to upgrade to 4.10.x
- protobuf gradle plugin need to bump a version compatible with gradle version.
- need add `google()` and `jcenter()` repos for android (otherwise `com.android.tools.build:aapt2:3.3.0x` and `trove4j` will not be found resp.)
- need to accept license for Android "build-tools;28.0.3" in kokoro env.
For Bazel, we upgrade to protobuf 3.6.1.2 and javalite HEAD to fix
incompatibilities in newer Bazel releases.
compiler/Dockerfile is unused, so it was removed instead of being updated.
protoc no longer includes codegen for nano, so we remain on the older protoc
any time nano is used.
Protobuf now requires C++11 when compiling, so windows was swapped to
VC 14.
- add CI for kotlin non-android
- bump kotlin version to fix kotlin compiler issue on jdk11
- add javax.annotation dep to fix kotlin build on jdk 9 & 11
Fixes#4725
It appears everything was already working on Java 11, except
build-specific and testing issues. Updating to Netty 4.1.30 (#4940)
probably fixed the last true Java 11 incompatibility.
Fixes#4933
There's no good way to provide users of ALTS a choice between grpc-netty
and grpc-netty-shaded. Since Netty is not exposed through the ALTS API
surface, we opt for the shaded version as it has fewer deployment
issues. However, this also means that we _can't_ expose any Netty API,
like EventLoopGroup.
The version bump happened in some places already, but many references
were missed.
This fixes the following warning that shows up with newer versions of
Gradle:
> Using TaskInputs.file() with something that doesn't resolve to a File
> object has been deprecated and is scheduled to be removed in Gradle
> 5.0. Use TaskInputs.files() instead.
grpc-netty is still really useful, but for most users who aren't doing
anything advanced using grpc-netty-shaded is much safer from a
dependency basis.
grpc-netty-shaded has seen more usage and has shown itself to be stable
and reduce the number of conflicts due to Netty versions.
This opens up the ability of dependency locking and the now-stable Maven
Publish Plugin. Also failOnVersionConflict no longer needs to be
commented out for the dependency insight report.
... with proper CA certificate to fix SSLV3_ALERT_HANDSHAKE_FAILURE in two host with different IPs setup, switch to required client auth to fail on incorrect configuration
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
The new jmh plugin fixes a warning for the newer version of Gradle.
The new AppEngine plugin still produces a warning, but updating it
anyway so people know that upgrading the plugin doesn't fix the problem.
The new android-maven plugin fixes a build problem with the newer
Gradle.
The Visual Studio fixes were necessary starting ~4.4.
https://github.com/gradle/gradle-native/issues/34#issuecomment-335222096
describes the change in behavior.
There's nothing immediately being used as part of this update. It's just
to keep us current and to get us over that Visual Studio change hump.
Updates include:
* Build file and dependency updates
* Correcting the gradle wrapper for the clientcache example
* Lint fixes (including making AsyncTask subclasses static)
* Dropping the m-prefix from member variables
* Fixing the code indentation
* Fixing and enabling proguard for the routeguide example.
Spies are really magical and easily produce unexpected results. Using them in
tests can easily yield tests that don't do what you think they do. Delegation
is much safer when possible.
Delegation doesn't work when methods `return true`, final methods, and with
restricted visibility, though. So CensusModulesTest and
MaxConnectionIdleManagerTest are left as-is.
This was deprecated with Bazel 0.8.0, which now uses
@com_google_protobuf instead.
This change will break users that use
grpc_java_repositories(omit_com_google_protobuf_java=True), so I've
added a custom error message to make the resolution clearer.
Refactor the proto file `helloworld_streaming.proto` because Bazel and Gradle have incompatible base directory for proto imports. Bazel's proto import is relative to WORKSPACE, whereas Gradle proto plugin's is relative to `${sourceSet}/proto/`. In `helloworld_streaming.proto` file, `import helloworld.proto` does not work for Bazel. If `import src/main/proto/helloworld.proto`, that works for Bazel, but Gradle and Maven would fail. Some workarounds are very hacky, so use independent proto without imports instead to avoid this issue.
This bump changelist is applied a bit late with respect to the
1.6.0 branch cut. Look at the 1.6.0 to see the source of truth of
where it was cut. Do not assume it is the commit that precedes
this one.
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes#3328
Class.forName(String) is understood by ProGuard, removing the need for
manual ProGuard configuration and allows ProGuard to rename the provider
classes. Previously the provider classes could not be renamed.
Fixes#2633
## Bazel
If you prefer to use Bazel:
```
(With Bazel v0.4.5 or above.)
$ bazel build :hello-world-server :hello-world-client
$ # Run the server:
$ bazel-bin/hello-world-server
$ # In another terminal run the client
$ bazel-bin/hello-world-client
```
The current check in ServerCallImpl is theoretically unsafe (#3059). Move that check into the stub, and expand the unit tests to cover other interesting edge cases on the server side:
client sends one, but zero requests received at onHalfClose
client sends one, but > 1 requests received at onHalfClose
server sends one, but zero responses sent at onComplete
server sends one, but > 1 responses sent via onNext
fixes#2243fixes#3059
migrated simple tests using `GrpcServerRule`.
Kept the low level in-process channel setup and tear down code for the RouteGuide example to show how users can use in-process directly to set more custom channel builder options when needed.
resolves#2490
Jihun Cho