Motivation:
JUnit 5 is more expressive, extensible, and composable in many ways, and it's better able to run tests in parallel.
Modifications:
Use JUnit5 in codec-smtp tests
Result:
Related to https://github.com/netty/netty/issues/10757
Motivation:
JUnit 5 is more expressive, extensible, and composable in many ways, and it's better able to run tests in parallel.
Modifications:
Use JUnit5 in codec-smtp tests
Result:
Related to https://github.com/netty/netty/issues/10757
Motivation:
When object-references are both same, the method should return 0 directly with no necessary go loop&compare the content of the ByteBuf.
Modification:
Added short circuit when both object-references are the same for equals and compare methods.
Result:
Added short circuit code.
Motivation:
1. The docs about the 'retun value' of the method `io.netty.util.internal.MathUtil#isOutOfBounds` is not correct.
2. The capacity parameter should be checked for overflowed case.
Modification:
1. Changed the doc to:
> @return {@code false} if the requested {@code index} and {@code length} will fit within {@code capacity}.
> {@code true} if this would result in an index out of bounds exception.
2. Improved the bounder checking logic.
Result:
Fixes#11279Fixes#11280
Motivation:
We shouldn't include benchmarks and tests in the generated javadocs to keep things clean
Modifications:
Add some more excludes
Result:
Javadocs for benchmarks and tests are not published
Motivation:
612ab58448 did change the way how netty-all was produced by unfortunally it messed up the dependency graph for our native artifacts. This commit reverts changes done by 612ab58448 and also clean up the profiles
Modifications:
netty-all is useable again
Result:
Fixes https://github.com/netty/netty/issues/11272
Motivation:
We should better fail the build if we can't load the OpenSSL library to ensure we not introduce a regression at some point related to native library loading
Modifications:
Remove usages of assumeTrue and let the tests fail if we cant load the native lib
Result:
Ensure we not regress
Motivation:
We need to ensure we correctly cleanup all the jars that are build for the integration tests that verify shading otherwise we may deploy these during release.
Modifications:
Correctly remove all the generated jars
Result:
Not deploy the jars by mistake
Motivation:
We shouldn't include netty-examples as dependency for netty-all as this will try to pull in all sorts of dependencies which are optional.
Modifications:
Remove dependency on netty-examples
Result:
Related to https://github.com/netty/netty/issues/11272
Motivation:
A user might want to handle a certain HTTP upgrade request differently
than what `HttpServerUpgradeHandler` does by default. For example, a
user could let `HttpServerUpgradeHandler` handle HTTP/2 upgrades but
not WebSocket upgrades.
Modifications:
- Added `HttpServerUpgradeHandler.isUpgrade(HttpRequest)` so a user can
tell `HttpServerUpgradeHandler` to pass the request as it is to the
next handler.
Result:
- A user can handle a certain upgrade request specially.
Motivation:
Older version of logback are affected by [CVE-2017-5929]. While its an optional dependency we should upgrade
Modifications:
Upgrade to 1.2.3
Result:
No more reports about using affected logback version
Motivation:
c443bc40fa removed the CI profile but we missed to adjust the docker-compose.yaml file
Modifications:
Remove -Pci as the profile doesn't exist anymore
Result:
No more warning during build
Motivation:
We used assumeTrue(...) in some places before to detect if we could load the native library but this could lead to the sitation that we not notice if we break native loading.
Modifications:
Always fail if we cant load the native library
Result:
Ensure we not cause any regression in the native loading code in the future
Motivation:
ccca3959fd fixed a regression which caused the native resolver code to not be loaded but this was not reported by the tests.
Modifications:
Adjust tests to actually fail the build if we cant load the native lib
Result:
Ensure we don't introduce another regression in the future
Motivation:
Cannot load the native library for DNS resolutions on MacOS.
The exception below is observed:
18:02:43.453 [Test worker] ERROR i.n.r.d.DnsServerAddressStreamProviders - Unable to load io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider, fallback to system defaults. This may result in incorrect DNS resolutions on MacOS.
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at io.netty.resolver.dns.DnsServerAddressStreamProviders.<clinit>(DnsServerAddressStreamProviders.java:64)
at io.netty.resolver.dns.DnsNameResolverBuilder.<init>(DnsNameResolverBuilder.java:60)
at reactor.netty.transport.NameResolverProvider.newNameResolverGroup(NameResolverProvider.java:432)
...
Caused by: java.lang.UnsatisfiedLinkError: io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider.resolvers()[Lio/netty/resolver/dns/macos/DnsResolver;
at io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider.resolvers(Native Method)
at io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider.retrieveCurrentMappings(MacOSDnsServerAddressStreamProvider.java:127)
at io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider.<init>(MacOSDnsServerAddressStreamProvider.java:123)
This is a regression made with #11239
Modification:
When checking for OS, an exception must be thrown when the OS is not MacOS
Result:
The native library for DNS resolutions on MacOS can be loaded
Motivation:
When changing the netty-all artifact to not include any sources we also removed the ability to generate the javadocs / xref files for our website
Modifications:
- Add new profile which will generate the files
- Add script which generates all the files and copy these over to the netty-website
Result:
Easier to generate files for website
Motivation:
The current initialization of Slf4JLoggerFactory is not singleton.
Modification:
Use Slf4JLoggerFactory.INSTANCE to initialize Slf4JLoggerFactory.
Result:
The instance of Slf4JLoggerFactory became a singleton.
Motivation:
After the release was done we need to also copy the apidocs and xref to the netty-website
Modifications:
Add script that does the copy etc
Result:
Less manual steps to remember
Motivation:
ParserImpl is stateless and so we can use the same instance multiple times
Modifications:
- Make constructor private
- Return the same instance all the time
Result:
Less object creation
Motivation:
DefaultHostsFileEntriesResolver should provide all hosts file's entries for a hostname when
DnsNameResolver#resolveAll as opposed to the current implementation where only the first
entry is taken into consideration
Modification:
- Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname
- Add HostsFileEntriesProvider to provide all hosts file's entries for a hostname and to keep
backwards compatibility for HostsFileEntries and HostsFileParser
- DnsNameResolver#resolveAll uses the new DefaultHostsFileEntriesResolver#addresses
- BlockHound configuration: replace HostsFileParser#parse with HostsFileEntriesProvider$ParserImpl#parse
as the latter does the parsing
- Add junit tests
Result:
Fixes#10834
Motivation:
`SelfSignedCertificate` creates a certificate and private key files and store them in a temporary directory. However, if the certificate uses a wildcard hostname that uses asterisk *, e.g. `*.shieldblaze.com`, it'll throw an error because * is not a valid character in the file system.
Modification:
Replace the asterisk with 'x'
Result:
Fixes#11240
Motivation:
Just use MAVEN_OPTS to setup all the timeouts etc for dependency downloads. This way we at least can be sure these are applied.
Modifications:
- Use MAVEN_OPTS
- Remove ci profile
- Remove unused settings.xml file
- Always use ./mvnw
Result:
Build stability improvements
Motivation:
We introduced the ability to offload certain operations to an executor that may take some time to complete. At the moment this is not enabled by default when using the openssl based SSL provider. Let's enable it by default as we have this support for some while now and didnt see any issues yet. This will also make things less confusing and more consistent with the JDK based provider.
Modifications:
Use true as default value for io.netty.handler.ssl.openssl.useTasks.
Result:
Offloading works with openssl based SSL provider as well by default
Motivation:
When trying to compile with java16 we should use adopt@1.16*
Modifications:
- Use adopt@1.16.0-1-
- Upgrade to blockhoud 1.0.6 to be able to support java16
Result:
Use correct java version / flavor
Motivation:
We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch
Modifications:
Adjust caching config to make use of different restore keys for maven caching but also docker caching
Result:
Better cache usage
Motivation:
We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible
Modifications:
- Just use the same cache for all
Result:
Hopefully be able to re-use most of the dependencies
Motivation:
TLSv1 and TLSv1.1 is considered insecure. Let's follow the JDK and disable these by default
Modifications:
- Disable TLSv1 and TLSv1.1 by default when using OpenSSL.
- Add unit tests
Result:
Use only strong TLS versions by default when using OpenSSL
Motivation:
Conscrypt not correctly filters out non support TLS versions which may lead to test failures.
Related to https://github.com/google/conscrypt/issues/1013
Modifications:
- Bump up to latest patch release
- Add workaround
Result:
No more test failures caused by conscrypt
Motivation:
`PlatformDependent#normalizedOs()` already caches normalized variant of
the value of `os.name` system property. Instead of inconsistently
normalizing it in every case, use the utility method.
Modifications:
- `PlatformDependent`: `isWindows0()` and `isOsx0()` use `NORMALIZED_OS`;
- `PlatformDependent#normalizeOs(String)` define `darwin` as `osx`;
- `OpenSsl#loadTcNative()` does not require `equalsIgnoreCase` bcz `os`
is already normalized;
- Epoll and KQueue: `Native#loadNativeLibrary()` use `normalizedOs()`;
- Use consistent `Locale.US` for lower case conversion of `os.name`;
- `MacOSDnsServerAddressStreamProvider#loadNativeLibrary()` uses
`PlatformDependent.isOsx()`;
Result:
Consistent approach for `os.name` parsing.
Motivation:
Mac OS specific DNS resolver fails to take into account search order
of resolvers causing wrong resolver being used is some circumstances
Modifications:
Re-order array of resolvers using their sort order as an ordering key.
Final order is opposite of the search order to make sure that resolver
with the lower sort order goes last (so it overrides previous one
in the `resolverMap`).
Result:
Fixes issue https://github.com/netty/netty/issues/11225
Motivation:
Netty lacks client side support for decompressing Brotli compressed response bodies.
Modification:
* Introduce optional dependency to brotli4j by @hyperxpro. It will be up to the user to provide the brotli4j libraries for the target platform in the classpath. brotli4j is currently available for Linux, OSX and Windows, all for x86 only.
* Introduce BrotliDecoder in codec module
* Plug it onto `HttpContentDecompressor` for HTTP/1 and `DelegatingDecompressorFrameListener` for HTTP/2
* Add test in `HttpContentDecoderTest`
* Add `BrotliDecoderTest` that doesn't extend `AbstractDecoderTest` that looks flaky
Result:
Netty now support decompressing Brotli compressed response bodies.
Motivation:
0f25213918 introduced some properties that were used to make builds more stable on the ci. All of these properties were duplicated everywhere, this made it hard to maintain
Modifications:
- Add profile which sets the properties.
- Just use the profile when build on the ci
Result:
Easier to maintain custom properties for the ci build
Motivation:
It seems like it is a known issue that maven frequently sees connection reset / connection timeout during CI builds. We should workaround these issues like others did:
- https://github.com/kiegroup/kie-wb-common/pull/3416
Modifications:
Add extra maven options during build to reduce the likelyness of timeouts / resets
Result:
More stable builds
Motivation:
We should add explicit null checks so its easier for people to understand why it throws.
Modification:
Add explicit checkNotNull(...)
Result:
Easier to understand for users why it fails.
Signed-off-by: xingrufei <xingrufei@sogou-inc.com>
Co-authored-by: xingrufei <xingrufei@sogou-inc.com>
Motivation:
When checking the latest commit i saw some bad exception messages in MqttVersion hence i improved them.
Modification:
Improved exception messages in MqttVersion.
Result:
Better exception messages in MqttVersion.
Motivation:
We've seen (very rare) flaky test failures due to timeouts.
They are too rare to analyse properly, but a theory is that on overloaded, small cloud CI instances, it can sometimes take a surprising amount of time to start a thread.
It could be that the event loop thread is getting an unlucky schedule, and takes seconds to start, causing the timeouts to elapse.
Modification:
Increase the initial timeouts in the SSLEngineTest, that could end up waiting for the event loop thread to start.
Also fix a few simple warnings from Intellij.
Result:
Hopefully we will not see these tests be flaky again.
Motivation:
DNS resolver falls back to trying CNAME if no records found, but should
only try this for A/AAAA queries. Does not make sense for other query
types, results in a redundant CNAME query that is just going to fail.
Modification:
Check query type before deciding to try CNAME. Only proceed if type is A
or AAAA.
Added unit test to verify CNAME is only tried after A/AAAA queries.
Result:
Fixes#11214.
Motivation:
`Http2FrameCodecBuilder` defines static factory methods `forClient()`
and `forServer()` that should be used to create a new instance.
The default ctor is useful only when users need to override behavior
of the existing builder. Those users should define another way to create
an instance.
Modifications:
- Decrease visibility of `Http2FrameCodecBuilder` default ctor from
`public` to `protected`;
- Add javadoc to clarity responsibilities;
Result:
Users of `Http2FrameCodecBuilder` are not confused why
`new Http2FrameCodecBuilder().build()` works for the server-side, but
does not work for the client-side.
Motivation:
The last non-LTS release is JDK16 now.
Modifications:
Update from JDK15 to JDK16 for building as this is the last non-LTS release atm
Result:
Build with latest non-LTS release as well
