Testing with Testcontainers, Arquillian and JUnit 5
by Harald Pehl
TLDR;
I've setup a PoC [1] for an alternative way to test the HAL management console.
The PoC is based on Testcontainers [2], Arquillian [3] and JUnit 5. Although
this is primarily intended for UI testing, the usage of Testcontainers could
also be interesting for the WildFly test suite.
---
The existing HAL test suite [4] is a rich test suite for the HAL management
console. It contains 300+ UI tests based on Arquillian [3].
The UI tests require a browser and a running WildFly instance as an execution
environment. This makes is hard to run the tests on a CI server. Another issue
is that the tests are not very stable and often run into timeouts. To execute
the complete test suite you need a stable environment.
Recently I came across Testcontainers [2], which provide a nice API to start
arbitrary containers before / after (all) unit tests. The library also provides
an elegant way to start and use browsers in remote web containers.
Therefore, I decided to implement a PoC which provides an alternative and
more stable way to test the HAL management console. Tests are self
contained and can run in CI environments such as GH Actions or Teamcity.
At the same time the new approach has to be compatible with the existing test
suite. Tests should be runnable w/o major code changes using the new approach.
The result is [1]. If you're interested, feel free to take a look and let me
know what you think!
---
[1] https://github.com/hpehl/manatoko
[2] https://www.testcontainers.org/
[3] http://arquillian.org/arquillian-graphene/
[4] https://github.com/hal/testsuite.next
2 years, 8 months
Embedded broker layer
by Emmanuel Hugonnet
Hello,
Currently there is no way to use layers to provision an embedded broker and I've been thinking about to provide such a layer.
The embedded broker configuration is done using the "messaging-activemq" feature group [1]. This feature group configure the embedded broker
itself, the ee default connection factory and the mdb part in the ejb3 subsystem.
Introducing an embedded broker layer requires several changes in the current layers:
- it should not be the responsibility of the embedded broker layer to configure mbd in the ejb3 subsystem, thus i propose to introduce a
new ejb-mdb layer that would depend on the ejb layer [2] and have an optional dependency on the embedded-broker layer.
- the embedded-broker layer would depend on the current messaging-activemq layer [3] and configure the ee default connection factory and
broker according to wht is already defined in the "messaging-activemq" feature group [1].
What do you think about this plan ?
Cheers,
Emmanuel
[1]: https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-comm...
[2]: https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
[3]: https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
2 years, 8 months
JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds
by David Delabassee
Greetings!
First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy
and prosperous new year!
In 2022, two Java releases will be made available:
- JDK 18 (March 2022)
- JDK 19 (September 2022)
JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be
better prepared for the future, it makes sense to begin testing your
project(s) using early access (EA) builds of JDK 19[3]. Your feedback
allows us to evaluate and address issues you find while testing EA builds.
This time, we have two heads-up to share:
## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal
Finalization is an outdated and brittle resource cleaning mechanism
present in the platform since, well, forever. Its use has been
discouraged for quite some time in favor of better alternatives (i.e.,
'try with resources' and Cleaners). JEP 421 is another step towards the
removal of finalizers as it offers tools to investigate if a codebase is
still using finalization. To learn more, you should read JEP 421[4]. You
should also listen to the latest episode of the Inside Java Podcast[5]
dedicated to this topic. We encourage you to check if your project is
still using finalizers. If so, you should start to think about removing
them and rely instead on either 'try with resources' or Cleaners.
## Heads-Up: JVM does not flag constant class entries ending in '/'
Prior to JDK 19, the JVM is loading classes (1) whose class file major
version is <49, i.e., before JDK 1.5, and (2) the class's name ends with
a '/'. This violates section 4.2.1 of the JVM specification [6] and is
addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a
ClassFormatError exception as it already does with newer classes (JDK
1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect
the compatibility risk to be very low.
For more details, see JDK-8278448[7].
[1] https://jdk.java.net/18/
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html
[3] https://jdk.java.net/19/
[4] https://openjdk.java.net/jeps/421
[5] https://inside.java/podcast/21
[6]
https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1
[7] https://bugs.openjdk.java.net/browse/JDK-8278448
## JDK 18
JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a
few weeks back when it entered RDP1.
### JEPs integrated to JDK 18:
- JEP 400: UTF-8 by Default
- JEP 408: Simple Web Server
- JEP 413: Code Snippets in Java API Documentation
- JEP 416: Reimplement Core Reflection with Method Handles
- JEP 417: Vector API (Third Incubator)
- JEP 418: Internet-Address Resolution SPI
- JEP 419: Foreign Function & Memory API (Second Incubator)
- JEP 420: Pattern Matching for switch (Second Preview)
- JEP 421: Deprecate Finalization for Removal
JDK 18 Early-Access builds 33 are now available[8], and are provided
under the GNU General Public License v2, with the Classpath Exception.
Also available are the Release Notes[9].
[8] https://jdk.java.net/18/
[9] https://jdk.java.net/18/release-notes
### Changes in JDK 18 since Rampdown Phase One that are of interest:
- JDK-8278373: Correcting References to Overloaded Methods in Javadoc
Documentation
- JDK-8279065: Deserialization filter and filter factory property error
reporting under specified
- JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs
- JDK-8275610: C2: Object field load floats above its null check
resulting in a segfault [Reported by Apache POI]
## JDK 19
JDK 19 Early-Access builds 7 are now available[10], and are provided
under the GNU General Public License v2, with the Classpath Exception.
Also available are the Release Notes[11].
[10] https://jdk.java.net/19/
[11] https://jdk.java.net/19/release-notes
### Changes in recent JDK 19 EA builds that maybe of interest:
- JDK-8279258: Auto-vectorization enhancement for two-dimensional array
operations
- JDK-8273914: Indy string concat changes order of operations
- JDK-8268081: Upgrade Unicode Data Files to 14.0.0
- JDK-8278087: Deserialization filter and filter factory property error
reporting under specified
- JDK-8276766: Enable jar and jmod to produce deterministic timestamped
content
- JDK-8274679: Remove unnecessary conversion to String in security code
in java.base
- JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
- JDK-8279064: New options for ktab to provide non-default salt
- JDK-8280055: JFR: Improve ObjectContext implementation
- JDK-8268831: Improve javadoc tool handling of streams
## Topics of Interest:
- "State of Valhalla" update
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2021-Decemb...
- Java's Plans for 2022 - Inside Java Newscast
https://inside.java/2022/01/13/insidejava-newscast-018/
- New Loom Early Access builds based on JDK 19 EAb2
https://mail.openjdk.java.net/pipermail/loom-dev/2021-December/003394.html
- New Panama Foreign Early-Access builds (including jextract) jdk 18
https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016131.html
- January 2022 Critical Patch Update Released
As part of the Jan 2022 Critical Patch Update we released JDK 17.0.2
LTS, JDK 11.0.14 LTS, JDK 8u321, and JDK 7u331 as well as OpenJDK 17.0.2
(publicly available). https://www.oracle.com/security-alerts/cpujan2022.html
In closing, I'd like to thank you again for being a welcomed part of the
Quality Outreach program! We look forward to your continued
participation in 2022. And as always, if you find an issue, please let
us know through the usual channels.
Regards,
--David
2 years, 9 months
wildfly, log4j2 CVE fixes and fix releases
by Andrew Marlow
Hello Wildflyers,
I see that wildfly 26.0.1 refers to log4j2 version 2.17.1 and this is good
due to the recent kerfuffle with log4j2 CVEs. However, I don't see this
being patched back to earlier wildfly versions. Is there any plan to?
I am on wildfly 23 and am using JDK8. There is a plan to eventually move to
JDK11 but it is some way off. Once we're there I expect it'll stay that way
for several years. So I am hesitant in moving to a more recent version of
wildfly - I am not sure what support there is for the older JDKs.
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
2 years, 9 months
