* Allow to pass instances of ClientConfig and Config to Hazelcast data store factory
This increases flexibility when configuring it programmatically.
Patterns such as
HazelcastSessionDataStoreFactory f = new HazelcastSessionDataStoreFactory();
f.setOnlyClient(true);
f.setClientConfig(ClientConfig.load());
or
HazelcastSessionDataStoreFactory f = new HazelcastSessionDataStoreFactory();
f.setServerConfig(Config.load());
can then be used to configure Hazelcast according to standard Hazelcast
locations if needed.
Co-authored-by: Jesse Glick <jglick@cloudbees.com>
> # 2022-09-14 Release of logback versions 1.3.1 and 1.4.1
> Logback components written for logback 1.2 should work without change in version 1.3. However, Joran, logback's configuration system, has been rewritten to use an internal representation model which can be processed separately. Thus, code depending on Joran needs to be adapted to changes in Joran (logback's internal configuration mechanism).
>
> As a result of enhancements to Joran, logback configuration scripts are now largely order-free. For example, appenders can now be defined after they are first referenced in a logger. Moreover, unreferenced appenders are no longer instantiated.
>
> - Logback-classic now correctly invokes DefaultJoranConfigurator when running in a (JPMS) modular environment. This fixes LOGBACK-1670 reported by Alexey Gavrilov who also provided the relevant test case.
> -Logback will now correctly retrieve its own version information when running in a (JPMS) modular environment. This fixes LOGBACK-1677.
> - Logback version 1.3.1 now correctly declares javax.servlet.ServletContainerInitializer as a provided service. This fixes LOGBACK-1671 as reported by Chad Wilson.
SLF4J 2.0.0, 2.0.1, and 2.0.2 have been released recently.
https://www.slf4j.org/news.html
> # 2022-09-20 - Release of SLF4J 2.0.2
> - Fixed bug in the setContextMap() method of Reload4jMDCAdapter. This issue was reported in [SLF4J-563](https://jira.qos.ch/browse/SLF4J-563) by Michael Wartes.
> - The binary of this version can be reproduced by checking out the tag v_2.0.2 from the source code repository (GitHub). Release built using Java "18" 2022-03-22 build 18+36-2087 under Linux Debian 11.2.
> # 2022-09-14 - Release of SLF4J 2.0.1
> - The Logger.makeLoggingEventBuilder method semantics has changed so that overriding implementations should now always build a new LoggingEventBuilder instance as appropraiate for the implementation, i.e the logging backend. For more details see [SLF4J-560](https://jira.qos.ch/browse/SLF4J-560).
> - Deprecated unused LoggerFactoryBinder and MarkerFactoryBinder classes. This issue was raised in [SLF4J-555](https://jira.qos.ch/browse/SLF4J-555) by Witalij Berdinskich who provided the relevant patch.
> - The binary of this version can be reproduced by checking out the tag v_2.0.1 from the source code repository (GitHub). Release built using Java "18" 2022-03-22 build 18+36-2087 under Linux Debian 11.2.
>
> # 2022-08-20 - Release of SLF4J 2.0.0
> The the 2.0.x series requires Java 8 and adds a backward-compatible [fluent logging api](https://www.slf4j.org/manual.html#fluent).
>
> Moreover, SLF4J has been modularized per [JPMS/Jigsaw](http://openjdk.java.net/projects/jigsaw/spec/) specification. The resulting internal changes are [detailed](https://www.slf4j.org/faq.html#changesInVersion200) in the FAQ page.
SLF4J 2.0.x series requires Java 8. It builds upon the 1.8.x series and adds a backward-compatible [fluent logging api](https://www.slf4j.org/manual.html#fluent). By backward-compatible, we mean that existing logging frameworks do not have to be changed for the user to benefit from the fluent logging API. However, existing frameworks must migrate to the ServiceLoader mechanism. The resulting internal changes are [detailed](https://www.slf4j.org/faq.html#changesInVersion200) in the FAQ page.
> - Except minor javadoc changes, this release is identical to 2.0.0-beta1 released earlier this month.
> - The binary of this version can be reproduced by checking out the tag v_2.0.0 from the source code repository (GitHub). Release built using Java "18" 2022-03-22 build 18+36-2087 under Linux Debian 11.2.
Let websocket-core handle any idleTimeout & writeTimeouts instead of bad attempt to do it in Jetty/Javax API layers.
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
* Updating to version 10.0.12
* Updating to version 10.0.13-SNAPSHOT
* VERSION.TXT =+ content of jetty-9.4.49.v20220914 release
* remove strange line and reorder
* Fixes#8558 - Idle timeout occurs on HTTP/2 with InputStreamResponseListener.
The issue was that HttpReceiverOverHTTP2.ContentNotifier.offer() was racy,
as a network thread could have offered a DATA frame, but not yet called
process() -- yet an application thread could have stolen the DATA frame
completed the response and started another response, causing the network
thread to interact with the wrong response.
The implementation has been changed so that HttpReceiverOverHTTP2.ContentNotifier
does not have a queue anymore and it demands DATA frames to the Stream
only when the application demands more -- a simpler model that just forwards
the demand.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Fixes#8532 - Review System.nanoTime() usages.
Introduced o.e.j.util.NanoTime class to deal with nanoTimes.
Now NanoTime.now() should be used instead of System.nanoTime(),
and various <unit>[elapsed|since|until]() methods to calculate nanoTimes.
Furthermore, comparing 2 nanoTimes should be done via isBefore(),
rather than using the < operator, which is wrong as specified in
the System.nanoTime() javadocs.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Joakim Erdfelt
dependabot[bot]
Simone Bordet
Greg Wilkins
Lachlan
Vincent Latombe
Jochen Schalanda
Olivier Lamy