Unrecoverable keys after opening the keystore could be a consequence of
the key having a different password than the keystore itself.
This could cause some people to spend a lot of time figuring out what's
going on, so let's just give them a quick heads up of a potential
(common?) reason for this error.
This could be fixed by running "keytool -keypasswd".
Without this patch, whenever a KeyStore is used (for example for client
certificates) in CLI mode, there is a message that no password was
provided.
This was caused by the else of the condition being on the wrong if
statement, and can cause people to spend a lot of time trying to debug
why the key store won't work.
A thread group might start later than the test. When we calculate delays on the start time of
the test, we might get a stampede of samples run at the start of the thread group.
When we use the test start time via JMeterContextService#getTestStartTime,
we might create a storm of test samples at the beginning, when a setup thread group
made us wait.
By providing this new class, this message can be prevented:
Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.
Sometimes in CI the brotli request will be redirected first, so try to not show
those redirects in the sampler output. Maybe we can get that test to working again.
The Log4j Core `packages` configuration attribute is deprecated because:
* It triggers the scanning of the mentioned packages and slows down the
startup process.
* It was replaced in version 2.0 by a faster mechanism that relies on a
`Log4jPlugins.dat` metadata file. See [Log4j Plugins](https://logging.apache.org/log4j/2.x/manual/plugins.html) for more details.
This PR removes the `packages` attribute from the standard configuration
file and configures the build script of `jmeter-core` to use the
`PluginProcessor` contained in `log4j-core`.
See #5937.
Motivation: if the value parses after trimming, then it would likely be the one
the user wants.
Currently, a trailing whitespace in UI is hard to notice, and it breaks test
execution. For instance ThreadGroup.threadNum becomes 0 without any warning,
and it invalidates test results.