Red Hat

Announcing public CI

We are proud to announce our public CI system, which is running integration tests for WildFly, WildFly Core, Undertow, and many other related projects. This system ensures that we do not merge anything that is broken and that our master is always stable.

CI also helps us with testing pull requests by:

  • Making sure the code works on most common target platforms, currently Linux and Windows.

  • Integration testing components as part of the full WildFly test suite. This is most often used when testing WildFly Core, where we test core itself as well as changes to core integrated on top of WildFly. This ensures that the latest core always works with the latest WildFly master.

  • Running additional test suites such as mixed-domain tests, which are a bit harder to set up and run locally.

  • Running complex integration tests that span across multiple projects, such as Elytron integration work that is landing in WildFly 11.

It is also utilized to test WildFly against various platforms and JDK combinations, such as testing the IBM JDK on Linux and Windows, testing Solaris SPARC, as well as regularly testing early builds of JDK 9. CI also produces nightly builds of WildFly and WildFly core, which you can follow on our forums.

We are using TeamCity as our CI with a few of our own customizations, including the following:

  • A bit-modified, unofficial TeamCity.GitHub plugin that allows us to post failed tests and other details of the failure to the pull request.

  • A pull-player, which we use as our trigger for pull requests. It provides us with a whitelisting of pull request authors for which CI tests are auto-triggered to prevent denial-of-service attacks. It also provides an option to retrigger CI testing by adding the comment “retest this please” to the pull request.

The system is powered by three servers running an ESXi hypervisor with everything else virtualized.

The front entry point is running Nginx with configured HTTP that is using an SSL certificate provided by Let’s Encrypt.

The infrastructure is managed by Ansible with a set of our playbooks.

We would like to thank JetBrains, which kindly donated the open source license for TeamCity.

Jigsaw’s Missing Pieces

Red Hat, with its years of experience supporting large scale software systems, has always been a strong proponent of modular Java. Over time, we have delivered many products and solutions that provide and support popular modular environments like Java EE, and OSGi. Since 2011, we introduced a flexible modular implementation called JBoss Modules, which is capable of supporting the core modularity needs of both Java EE and OSGi, but is usable in a standalone manner, without the need to bring in the full platform those specifications require. JBoss EAP and WildFly are built on this technology, which is a major contributor to the flexible runtime they provide.

While the above technology allows us to meet the needs of our customers as well as our own, we are hopeful that JSR-376 (Java Platform Modular System), also known as Project Jigsaw, will provide a standardized solution that could be embraced by the full Java community and lead to better software and better interoperability. Additionally, the Java EE expert group has long wanted to improve the overall modularity of the platform, but has deferred these goals hoping to leverage the common SE technology to be introduced by the above JSR.

These goals were widely shared as noted in the agreed upon JSR submission. Relevant sections include:

  • “This JSR will define an approachable yet scalable module system for the Java Platform. It will be approachable, i.e., easy to learn and easy to use, so that developers can use it to construct and maintain libraries and large applications for both the Java SE and Java EE Platforms.”

  • ”This JSR targets Java SE 9. We expect the module system to be leveraged by Java EE 9, so we will make sure to take Java EE requirements into account.”

  • ”Some members of the Java community have already invested significantly in applications and frameworks built on top of the OSGi Service Platform. The module system will provide a means for an OSGi kernel to locate Java modules and resolve them using its own resolver, except possibly for core system modules. This will enable OSGi bundles running in such a kernel to depend upon Java modules.”

Unfortunately, Jigsaw (JSR-376’s implementation), suffers from a number of significant gaps which may prevent these goals from being fully achieved. As currently defined, Jigsaw is not capable of fully supporting Java EE, OSGi, or any other system with similar dynamic capabilities. However in recent weeks, there have been a number of proposals and discussions to address these problems.

We believe it’s critical that these gaps are addressed, as the existence of multiple incompatible standards would likely fragment the Java ecosystem. Application developers would be forced to artificially choose between a totally new static oriented universe of software based on Jigsaw, and the already existing universe, which handles more use-cases and encompases traditional Java SE, Java EE, and OSGi. Framework developers may attempt to support both, but they will likely incur additional cost and potential defects to do so. Finally, divergence will likely increase as standards such as Java EE 9 are forced to consider other options.

While there are a number of issues under discussion, they can be categorized into the following areas:

  1. Reflection is disallowed from operating on non-exported types, even with the use of setAccessible [1]. This breaks anything using dependency injection or custom serialization (Java EE, Hibernate, Spring, CDI, JAXB, etc). The current proposal put forth by Oracle addresses this by allowing the user to declare packages “open” for reflection.

  2. Jigsaw has only limited support for the dynamic introduction and alteration of modules [2]. This prevents modeling Java EE deployments or OSGi bundles as sets of modules as both require support for dynamic installation and hot redeployment. While layers could potentially act as a solution, layers do not support peer-to-peer inter-layer dependency graphs [3]. Additionally everything is eagerly loaded, with a complete graph required to be known up front [4]. This problem is still under active discussion, with some partial proposals. If certain hooks are added, it may be possible to bypass Jigsaw’s native dependency resolution to work around the issue. On the other hand, this has some drawbacks. It requires replicating Jigsaw’s resolution in a dynamic fashion, and it will likely hide information from reflection that a developer might wish to see, but it opens the door for advanced/specialized behavior.

  3. Restrictions that make interoperability with alternative modular systems difficult. [5] [6] [7]. Bypassing or mangling Jigsaw’s dependency resolution would allow for a custom implementation to provide support for cyclic dependencies [5]. There is a proposal to allow more flexibility in terms of allowed characters and escaping with module names [6].

In summary, we believe fragmentation of the Java ecosystem must be avoided, as it will overly burden Java developers and stifle innovation. We remain hopeful that continued progress on these issues will not only prevent such an outcome, but allow the full Java community to embrace and benefit from standardized modularity.

WildFly 10.1 is now available!

WildFly 10.1 is officially complete and available for download!

Major new features include:

  • Out of the box HTTP/2 support with no JVM flags required !

  • TLS cert auto-generation

  • Load-balancing profile is now in our default domain.xml config

  • Support for clustering node discovery on Azure (jgroups AZURE_PING)

Additionally there was a massive 324 issues resolved in this release!

Out of the Box HTTP/2 and TLS

Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.

Load-balancing Profile

In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.

Jira Release Notes

The full list of issues resolved is available here.

back to top