Version 1

    The fifth WildFly 10 release candidate is now available for download on



    Java EE 7

    As with WildFly 8 and WildFly 9, WildFly 10 implements the Java EE 7 Full and Web Profile standards.

    Java 8+


    Java 7 support has been discontinued allowing for deeper integration with the Java 8 runtime. While Java 9 is still in development, this release runs on the current development snapshots.



    ActiveMQ Artemis


    Late last year, the HornetQ codebase was donated to the Apache ActiveMQ project, and the HornetQ community joined to build a next-generation messaging broker. This was materialized in the first major release of the ActiveMQ Artemis project. ActiveMQ Artemis includes many new features, and also retains protocol compatibility with the HornetQ broker. WildFly 10 Beta includes this new exciting project as its JMS broker, and due to the protocol compatility, it fully replaces the HornetQ project.



    Offline CLI Support for Domain Mode

    In addition to the offline CLI support for standalone mode, you can now launch a host-controller locally within the CLI. Using the embed-host-controller command you can edit the content of domain.xml and host.xml without launching additional processes or opening network sockets.



    JavaScript Support with Hot Reloading

    WildFly 10 includes the Undertow JS project, which allows you to write server side scripts that can pull in CDI beans and JPA Entity Beans. This can be quite useful for throwing together a quick view layer (perhaps using a templating language like Mustache, or a framework like Angular), or quickly developing a REST endpoint. You can edit the JS files live on the system, and they are dynamically reloaded, without having to redeploy your application.

    For more details see the following blog post: Using Server Side Javascript with Wildfly · WildFly

    HA Singleton Deployments


    WildFly 10 adds the ability to deploy a given application as a "singleton deployment". This is a new implementation of a feature that existed in AS 6.0 and earlier. When deployed to a group of clustered servers, a singleton deployment will only deploy on a single node at any given time. If the node on which the deployment is active stops or fails, the deployment will automatically start on another node. The policies for controlling HA singleton behavior are managed by a new "singleton" subsystem.  A deployment may either specify a specific singleton policy or use the default subsystem policy. A deployment identifies itself as singleton deployment via a /META-INF/singleton-deployment.xml deployment descriptor (the schema for which can be found here: wildfly/singleton-deployment_1_0.xsd at master · wildfly/wildfly · GitHub), which is most easily applied to an existing deployment as a deployment overlay. Alternatively, the requisite singleton configuration can be embedded within an existing jboss-all.xml.


    HA Singleton MDBs and MDB Delivery Groups


    Another advanced clustering capability in WildFly 10, singleton MDBs supports infrastructures which require message delivery on only single host at a time. In the event of a failure, another host in the cluster with the same application deployed will take over message processing.


    MDB delivery groups allow an administrator to selectively enable and disable a "delivery group" via a management operation, which is composed of one or more MDBs. This capability supports environments with an external custom failover mechanism. As with all management operations, these calls are accessible from the many management interfaces of WildFly, including the CLI, a Java API, and an HTTP/JSON API.


    SLSB and MDB Automatic Pool Sizing


    WildFly now pools stateless session beans by default, using a pool size that is computed relative to the size of the IO worker pool, which is itself auto-tuned to match system resources. Additionally MDBs now use a pool which is similarly tuned to a value derived from the number of CPUs on the system. Previously stateless sessions beans did not pool by default, and MDBs used a pool with a small hard-coded size. The values chosen are logged to an INFO message as part of startup. Manual tuning is still supported using the same max-pool-size attribute.


    Note that the default configurations shipped with WildFly 10 enable automatic pool sizing by using the derive-size attribute. Configurations used with previous versions of WildFly will need to be updated to take advantage of this capability. The intention is to preserve existing behavior as past configurations may have been explicitly tuned to best match deployed applications. While this capability improves the default pool size, achieving maximum performance would likely require specifically setting the size to match the patterns and needs of the application.


    Migration Operations for Discontinued Subsystems


    To help users migrating from old subsystems such as jbossweb (AS 7.1), jacorb (WildFly 8), and hornetq (WildFly 9), we have introduced a set of management operations that can convert old configuration over to the new respective subsystem equivalent. Since these operations migrate the underlying management resource model, old CLI scripts or custom provisioning systems can also take advantage of these.


    Capabilities and Requirements

    Subsystem developers now have the ability to negotiate interaction with other subsystems in a more pluggable way. This allows for subsystems to have dependencies that can be satisfied by more than one subsystem, which is particularly useful in providing multiple implementations of the same underlying capability. Additionally it leads to improved error reporting. Instead of a failure being reported at the service layer, which is how the WildFly runtime is mapped, it is instead reported at a higher level that is easier to connect to the server's configuration  As an example, a missing socket binding is now reported as a missing socket binding, as opposed to a list of services with an unsatisfied dependency. Expect to see overall error reporting in WildFly improve as subsystems begin to adopt this ability

    For more information, see the development guide.



    Hibernate 5


    Hibernate 5 includes several additional improvements, such as greatly improved bytecode enhancement, which is a useful performance optimization. Additionally a number of API improvements are provided, including use of generics in Hibernate Native, and an improved SPI for second level cache providers. Also included are new and improved schema update and validation tooling.



    Batch (JSR-352)


    Previously the batch subsystem was located under the path subsystem=batch. It has been moved to subsystem=batch-jberet with some changes to the subsystem model. WildFly 8 and 9 configuration files will still boot and work under under the subsystem=batch path.


    To highlight the changes in the management model. Two new resources were added in-memory-job-repository and jdbc-job-repository. You can have any number of these new resources defined, but the name must be unique across all *-job-repository resources. The job-repository-type attribute has been removed and replaced with a default-job-repository attribute. The value for this attribute is one of the defined job repositories.


    Finally since you can have multiple job repositories you can also have multiple thread pools. These can be used in a jboss-all.xml deployment descriptor.


    Batch handling has been improved with graceful shutdown and server suspend mode. When entering server suspend mode, all batch jobs are gracefully stopped at the next checkpoint. When leaving server suspend mode, back into running state, all jobs stopped during suspension are then restarted.


    You can read more about batch in the WildFly documentation.


    Powershell scripts


    Powershell scripts ware added to bin directory of WildFly distribution and are meant to fully replace .bat scripts in future releases.

    They provide same functionality as .bat scripts and additionally address handful of issues found in batch scripts.



    JIRA Release Notes


    For more details on the release see the following WildFly JIRA release notes:


    ReleaseIssues Resolved
    10.0.0.CR5    Release Notes150
    10.0.0.CR4    Release Notes66
    10.0.0.CR3    Release Notes29
    10.0.0.CR2    Release Notes40
    10.0.0.CR1    Release Notes 107
    10.0.0.Beta2  Release Notes42
    10.0.0.Beta1  Release Notes63
    10.0.0.Alpha6 Release Notes39
    10.0.0.Alpha5 Release Notes41
    10.0.0.Alpha4 Release Notes37
    10.0.0.Alpha3 Release Notes33
    10.0.0.Alpha2 Release Notes10
    10.0.0.Alpha1 Release Notes30


    Additionally the following WildFly Core JIRA release notes:


    ReleaseIssues Resolved
    2.0.5.Final  Release Notes8
    2.0.5.CR1    Release Notes19
    2.0.4.Final  Release Notes12
    2.0.3.Final  Release Notes11
    2.0.2.Final  Release Notes16
    2.0.1.Final  Release Notes2
    2.0.0.Final  Release Notes7
    2.0.0.CR9    Release Notes7
    2.0.0.CR8    Release Notes12
    2.0.0.CR7    Release Notes34
    2.0.0.CR6    Release Notes16
    2.0.0.CR5    Release Notes4
    2.0.0.CR4    Release Notes6
    2.0.0.CR2    Release Notes16
    2.0.0.CR1    Release Notes6
    2.0.0.Beta7  Release Notes20
    2.0.0.Beta6  Release Notes16
    2.0.0.Beta5  Release Notes21
    2.0.0.Beta4  Release Notes1
    2.0.0.Beta3  Release Notes13
    2.0.0.Beta2  Release Notes5
    2.0.0.Beta1  Release Notes2
    2.0.0.Alpha13 Release Notes10
    2.0.0.Alpha12 Release Notes4
    2.0.0.Alpha11 Release Notes14
    2.0.0.Alpha10 Release Notes9
    2.0.0.Alpha9  Release Notes31
    2.0.0.Alpha8  Release Notes9
    2.0.0.Alpha6  Release Notes14
    2.0.0.Alpha5  Release Notes26
    2.0.0.Alpha4  Release Notes10
    2.0.0.Alpha3  Release Notes18
    2.0.0.Alpha2  Release Notes4
    2.0.0.Alpha1  Release Notes12