Blocking can be confused with the blocking stub, which is unrelated. I'm
purposefully not saying "it is used only for X," as that isn't what we
need from the API. But it is still helpful to users to describe the
sorts of things that use it.
Fixes#10508
OverrideAuthority() is the modern alternative to rewriting the
InetAddress, and can also work if we change the channel creation to use
target strings instead. We can use test CAs now without resorting to the
Netty-specific APIs. After this change, only 4 classes in
interop-testing depend on Netty.
* Use internalClose instead of close when sendMessage has a RuntimeException.
* Change argument to internalClose to a Throwable instead of a Status.
* Rename internalClose to handleInternalError
Interop-testing is both binaries and a library. It hadn't been updated
to use java-library and to expose API-surface dependencies to
dependents.
This fixes the error:
```
> Task :grpc-gae-interop-testing-jdk8:javadoc FAILED
javadoc: error - An internal exception has occurred.
(com.sun.tools.javac.code.Symbol$CompletionFailure: class file for io.grpc.internal.testing.StreamRecorder not found)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for io.grpc.internal.testing.StreamRecorder not found
1 error
```
Instead of adding explicit dependsOn to compileJava and sourcesJar,
adding the sync task to the sourceSet automatically propagates the
dependency to all consumers of the code.
* Mark MultiChildLoadBalancer as Internal. Cannot move to the internal package because of its use of classes in the util package.
* Exclude MultiChildLoadBalancer from javadoc generation.
* Fix javadoc creation.
The scripts used `git rev-parse --show-toplevel` so it appeared they
could be used from any directory. But references to "GIT_BASE_DIR"
weren't absolute, so it did matter the starting directory. And it
mattered in a big way for xds/import.sh as if you ran it from the
grpc-java directory it would delete the xds directory in grpc-java, not
third_party.
The trap that deleted the GIT_BASE_DIR was very broken. In addition to
potentially deleting the wrong directory, it was unnecessary because
that directory was in tmpdir. But you can only have one trap per signal,
so this unnecessary trap disabled the trap that deleted tmpdir.
The script needed a full clone because it needed to check out a specific
commit. To work with --depth 1 you have to use some convoluted syntax.
But just downloading a tar.gz is easy and seems should work fine on Mac.
protoc-gen-validate/import.sh didn't have the trap problem, but seemed
to have drifted from the other scritps. All the scripts were synced to
match.
Even though we don't really use japicmp, the configuration was resolving
artifacts even when the task was not executed. After some clean up, the
configuration looks more ordinary.
While not easy to use because java_grpc_library() uses a fixed
toolchain, it is possible for downstream users to apply a patch to the
repo to add their own annotation processors. This feature was added
inside Google so exporting it reduces the diff between internal and
external and causes no harm.
cl/280287611
This allows okhttp to service the Grpc.newServerBuilderForPort() API.
Note that, unlike Netty, it will throw if you try to use
ServerBuilder.forPort().
This fixes android-interop-testing which was broken by c9864a119.
OutlierDetectionLoadBalancer did not delegate calls to an existing
ClientStreamTracer from the tracer it installed. This change has the OD
tracer delegate all calls to the underlying one.
We have the OkHttp server these days, so we don't need to use Netty. Use
the generic API instead of hard-coding OkHttp.
We've seen some recent interop failures. We aren't entirely sure what is
going on, but we have seen some Netty usages in logcat. Since we don't
even want Netty on Android, just get rid of it and even if it doesn't
help with the failures things are better dependency-wise.
The README describes the released version of gRPC. But the most recent
release doesn't use protobuf 3.23.4. Telling people to use protoc 3.23.4
is asking for breakages because they will be running with protobuf-java
3.22.3, which is a downgrade.
The bump to 3.23.4 was incorrectly done in #10359.
Most changes are migrating from conventions to the equivalent
extensions. JMH, AppEngine, and Jib plugins trigger future compatibility
warnings with `--warning-mode all`.
The movement of configurations was to allow sourceSets to create the
configurations and then we just configure them. When configurations were
before sourceSets, we'd implicitly create the configuration.
The examples were _not_ updated to the newer Gradle, although the
non-Android examples work with the newer Gradle. The Android examples
use an older Android Gradle Plugin which will need to be upgraded first.
https://github.com/grpc/grpc-java/issues/10445
While JacocoReportBase.getExecutionData() is properly annotated with
`@InputFiles` and is a FileCollection, which can propagate dependencies,
the JacocoPlugin's configuration of the task [goes through a
File][barefile], which doesn't propagate task dependency information.
This is overcome in the plugin by mustRunAfter. This may have been on
purpose to allow jacocoTestReport to report on the subset of tests
already run, but is atypical these days.
Because of that, we need to copy the mustRunAfter from the other
JacocoTestReports. The dependsOn weren't doing anything because there
were no dependsOn; that configuration is quite old so it's hard to say
when they stopped functioning.
This fixes warnings like:
```
- Gradle detected a problem with the following location: 'grpc-java/core/build/jacoco/test.exec'. Reason: Task ':grpc-all:jacocoTestReport' uses this output of task ':grpc-core:test' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
- Gradle detected a problem with the following location: 'grpc-java/testing/build/resources/main'. Reason: Task ':grpc-all:jacocoTestReport' uses this output of task ':grpc-testing:processResources' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
```
I was able to trigger the warnings by:
```
./gradlew clean
./gradlew :grpc-core:test
./gradlew :grpc-all:jacocoTestReport
./gradlew :grpc-core:test :grpc-all:jacocoTestReport
```
[barefile]: bc4029063c/subprojects/jacoco/src/main/java/org/gradle/testing/jacoco/tasks/JacocoReportBase.java (L162-L168)
Stephane Landelle
Eric Anderson
kotlaja
Terry Wilson
Larry Safran
yifeizhuang
Tony An
sanjaypujare
Sergii Tkachenko
Mohan Li
Zach Reyes