Bring your own JSF implementation to Open Liberty 17.0.0.4

And, like a flash, a second release of Open Liberty (17.0.0.4) is upon us! Fancy bringing your own JSF implementation (Mojarra or MyFaces) to Open Liberty? You can now (and benefit from CDI) with the JSF Container 2.2 feature. Also, administrators can now configure concurrency policies for managed executors (Concurrency updates), and get distributed tracing with our implementation of opentracing.io.

As we don’t have a full set of documentation implemented for Open Liberty yet, the items below point (where relevant) to the official documentation for WebSphere Liberty (which is built on Open Liberty) so you can find out more about them.

JSF Container 2.2

This feature makes it possible to bring your own JSF implementation (either Mojarra or MyFaces) for JSF 2.2 and take advantage of CDI integrations provided by the cdi-1.2 feature.

To try this, enable the jsfContainer-2.2 feature in your server.xml, and package your own JSF API and implementation inside of your application and off you go!

<featureManager><feature>jsfContainer-2.2</feature></featureManager>

Concurrency

The administrator is now able to configure concurrency policies for managed executors for finer-grained control over concurrency constraints and other behavior. This includes how many tasks are allowed to run in parallel, how many tasks can queue up, and what action to take when it is not possible to queue a task for execution, among other behaviors. Different policies can be assigned for long-running tasks (identified by the LONGRUNNING_HINT execution property) versus normal tasks. Managed executors continue to be backed by the Liberty global thread pool and continue to benefit from Liberty’s autonomic tuning, but it is now possible to impose these constraints to individual managed executors or groups of managed executors (multiple can share a single concurrency policy).

To try it out, configure one or more concurrency policies in the server.xml file. For example:

In an environment with numerous services communicating with each other, distributed trace information provides a way to view the end-to-end flow of requests through multiple services. In many environments, there is a central trace collection service that accepts distributed tracing information from individual applications (one popular distributed tracing service is Zipkin). The central service correlates the distributed tracing information, and presents the end-to-end request flow information with a UI.

The opentracing.io project defines an API that applications can use to create, propagate, and deliver distributed trace information. An implementation of the opentracing.io API must be available to an application so that the application can deliver distributed trace information. The implementation of the opentracing.io API must match the implementation of the central trace collection service. For example, if the central trace collection service is Zipkin, then the opentracing.io implementation used by applications must perform distributed tracing functions in a way that is specific to Zipkin.

Typically, the developer of each application in the environment must explicitly add code to the application in order for it to create, propagate, and deliver distributed tracing information. With the opentracing-1.0 feature of Liberty, developers do not need to add any code to their JAX-RS applications to participate in distributed tracing. The JAX-RS application will automatically create, propagate, and deliver distributed tracing information.

Each Liberty server in the environment must be configured with a user feature that provides an implementation of the opentracing.io API. The user feature must provide an implementation of the opentracing.io API that matches the central trace collection service that is used in the environment.