| layout | title | date | categories | author_picture | author_github |
|---|---|---|---|---|---|
post |
Bring your own JSF implementation to Open Liberty 17.0.0.4 |
2017-12-21 12:05:00 +0100 |
blog |
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.
Remember, if you’re really keen, you can see what’s being developed in Open Liberty in the nightly builds. Feel free to raise or even fix a bug. Fancy influencing the future direction of Open Liberty? Join the Open Liberty discussion group.
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.
You can now download Open Liberty and Open Liberty Tools 17.0.0.4.
Alternatively, if you’re using Maven, here are the coordinates:
<dependency>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>17.0.0.4</version>
<type>zip</type>
</dependency>Or if you’re using Docker:
docker pull openliberty/open-libertyIn Open Liberty 17.0.0.4, you’ll find :
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>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:
<concurrencyPolicy id="max10" max="10" maxQueueSize="30" maxWaitForEnqueue="20s" startTimeout="1m"/>Managed executors can be configured to use the concurrency policy as follows:
<managedExecutorService jndiName="concurrent/executor1" concurrencyPolicyRef="max10"/>
<managedScheduledExecutorService jndiName="concurrent/executor2" concurrencyPolicyRef="max10"/>For more info, see the WebSphere Liberty Knowledge Center docs on Configuring the managed executor service and Configuring the managed scheduled executor service.
The opentracing-1.0 feature, together with a user provided io.opentracing.Tracer implementation, enables JAX-RS applications to automatically create, propagate, and deliver distributed tracing information.
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.
You can find sample source code for a user feature that provides a Zipkin-specific opentracing.io API implementation on GitHub. Or you can download a built version of the user feature from Maven Central.