Red Hat

MicroProfile 3.2 in WildFly 19.0.0.Beta1

I’m pleased to announce that the WildFly 19 Beta1 zip is now available for download.

I typically don’t blog about the WildFly betas, but I want to this time because I’m so thrilled to be able to say we’ve gotten implementations of all of the MicroProfile 3.2 specifications in this release! This is the first WildFly release that includes all the MicroProfile platform specs.

We’ve added three new subsystems to provide support for the MicroProfile platform specs we’ve never supported before:

Specification Version in WildFly 19 JIRA Issue

MicroProfile Fault Tolerance



MicroProfile JWT Authentication



MicroProfile OpenAPI



MicroProfile 3.2 also includes updates to two of the specs we included in WildFly 18, so those have been updated as well:

Specification Version in WildFly 19 JIRA Issue

MicroProfile Health Check



MicroProfile Metrics



As we did in WildFly 18, we also provide MicroProfile Config 1.3, OpenTracing 1.3, and Rest Client 1.3, the implementations of which have had some updates. In particular, the subsystem for integrating OpenTracing has been updated to provide a richer management API. Finally, we of course provide all of the MicroProfile specs that are also part of Java EE 8.

WildFly’s MicroProfile implementations are primarily based on the Smallrye projects. (We use RESTEasy’s Rest Client impl.) Many thanks to Ken Finnigan and all the folks in the Smallrye community for providing great implementations of these rapidly evolving specs!

It takes a great community to bring in major new features like this. A great number of other folks have helped; I thank you all and my apologies to anyone I’ve missed:

  • Fabio Burzigotti

  • Michael Edgar

  • Paul Ferraro

  • Emmanuel Hugonnet

  • Radoslav Husar

  • Jan Kasik

  • Kabir Khan

  • Darran Lofthouse

  • Eduardo Martins

  • Stefano Maestri

  • Jeff Mesnil

  • Miroslav Novak

  • Ron Sigal

  • Alessio Soldano

  • Tobias Stadler

  • Martin Stefanko

  • Ivan Straka

  • Rostislav Svoboda

  • Sultan Zhantemirov

I’d particularly like to thank Stefano Maestri for his leadership in getting this done, and Michael Edgar and Tobias Stadler for providing a lot of the drive behind this — and for putting up with our sometimes burdensome feature development processes!

Jira Release Notes

I’ll wait for the WildFly 19 Final release to get into all the details, but 19.0.0.Beta1 includes a wide variety of other features, component updates, bugs fixes and enhancements beyond the MicroProfile work. The full list of issues resolved is available here. This release incorporates WildFly Core 11.0.0.Beta7 — see the WildFly Core JIRA for details of what was in the WildFly Core 11 betas.

Enjoy, and as always, thank you so much for your support of WildFly!

WildFly 19.0.0.Beta3 with Eclipse MicroProfile 3.3 Support

I’m pleased to announce that with today’s WildFly 19.0.0.Beta3 release WildFly supports the Eclipse MicroProfile 3.3 platform specifications! The WildFly 19 Beta3 zip is now available for download.

With the January release of WildFly 19 Beta1 we added support for MicroProfile 3.2. Since the MicroProfile 3.3 release was coming in February and the delta from 3.2 wasn’t too extreme we decided to go ahead and delay WildFly 19 a bit and go for MicroProfile 3.3 support. Thanks to some heroic efforts from the WildFly developers and testers and a huge assist from the Smallrye community we’ve been able to get this done. Thank you all, and congratulations on this achievement!

WildFly now provides support for the following MicroProfile specifications:

Specification Version in WildFly 19

MicroProfile Config


MicroProfile Fault Tolerance


MicroProfile Health Check


MicroProfile JWT Authentication


MicroProfile Metrics


MicroProfile OpenAPI


MicroProfile OpenTracing


MicroProfile Rest Client


We also provide all of the MicroProfile specs that are also part of EE 8.

As I noted in my post about the 19.0.0.Beta1 release, WildFly 19 includes three new subsystems to provide the MicroProfile specs that weren’t in WildFly 18: microprofile-fault-tolerance-smallrye, microprofile-jwt-smallrye and microprofile-openapi-smallrye.

We’ve also added two new standard configuration files to help guide users toward server configurations well suited for microservice use cases:

  • standalone-microprofile.xml

    • Provides our MicroProfile platform implementations combined with JAX-RS and technologies JAX-RS applications commonly use to integrate with external services.

  • standalone-microprofile-ha.xml

    • Similar to standalone-microprofile.xml but with support for high availability web sessions and distributed Hibernate second-level caching.

Our other standard config files (e.g. standalone.xml) also include the subsystems needed to support Config, JWT, Health, Metrics, OpenTracing and Rest Client. The inclusion of JWT is new with the Beta 3 release.

On to Final!

We plan to have a pretty short bake period for this beta during which we’ll get a couple more bug fixes in and then we’re shooting for the WildFly 19 Final release in 5 to 10 days.

Enjoy, please give us feedback, and as always, thank you so much for your support of WildFly!

Custom Filters in WildFly

What is a log filter?

A log filter is used to add fine grained control over a log message. In the case of WildFly this is a java.util.logging.Filter. As of WildFly 18 there is the ability to use custom log filters.

Creating a Filter

To create a filter you must implement the java.util.logging.Filter interface. The filter must be in a module and can be defined on a logger or a handler via the filter-spec attribute. A custom filter can also be combined on the filter-spec attribute with a filter expression. For example any(match(".*WELD.*"), myCustomFilter).

The below example will filter log messages based on the current thread’s context class loader. It takes advantage of WildFly’s use of JBoss Modules to get the module name from the class loader. The name is then checked to see if it matches the pattern configured on the filter.

Example Filter

public class ClassLoaderFilter implements Filter {

    public boolean isLoggable(final LogRecord record) {
        final ClassLoader cl = getClassLoader();
        String value;
        if (cl instanceof ModuleClassLoader) {
            value = ((ModuleClassLoader) cl).getName();
        } else {
            value = cl.toString();
        if (pattern == null || pattern.matcher(value).matches()) {
            MDC.put("moduleName", value);
            return true;
        return false;

Adding a Filter

A filter can be added to WildFly by first creating a module based on the library the filter is in. We then need to create a filter resource on the logging subsystem based on this new module and filter. Finally the filter can be added to a logger or handler resource.

Example CLI Commands

module add --name=org.jboss.example.filter --resources=/path/to/log-filter.jar --dependencies=org.jboss.modules,java.logging,org.jboss.logging
/subsystem=logging/json-formatter=json:add(exception-output-type=formatted, date-format="yyyy-MM-dd'T'HH:mm:ss.SSSZZZZZ")
/subsystem=logging/filter=clFilter:add(module=org.jboss.example.filter, class=org.jboss.example.filter.ClassLoaderFilter, properties={pattern=".*deployment\.app.*"})
/subsystem=logging/file-handler=DEPLOYMENT:add(file={relative-to=jboss.server.log.dir, path=deployment.log}, level=TRACE, append=false, autoflush=true,named-formatter=json, filter-spec=clFilter)

In the example above we create a filter which uses the pattern .*deployment\.app.*. This will match the module name from the current thread’s context class loader and only accept messages where the module name matches the pattern. In our case this will only log messages that are associated with our deployment.

We then add the filter created to the file handler created with a JSON formatter. Finally we add the file handler to the root logger.

Example Project

An example project can be found at To use the example project simply download the source and run mvn clean wildfly:run. Once started and the application is deployed you can access the example at http://localhost:8080/app.

You should initially see some log messages that were logged during the deployment process. You can then log a custom message or start a job which logs a message at the defined number of seconds.

back to top