WildFly 10 Final released !

On the 29th January 2016 WildFly 10 Final has been released! Let’s have a quick breakthough its features.

New messaging subsystem: the new messaging provider embedded in WildFly 10 is Apache Artemis MQ which is derived from the HornetQ project, recently donated to the Apache foundation. The new messaging provides retains compatibility with the former HornetQ both in terms of architecture components (Acceptors/Connectors) and in terms of default destination names:

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
    <server name="default">
        <security-setting name="#">
            <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
        </security-setting>
        <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
        <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
        <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
            <param name="batch-delay" value="50"/>
        </http-connector>
        <in-vm-connector name="in-vm" server-id="0"/>
        <http-acceptor name="http-acceptor" http-listener="default"/>
        <http-acceptor name="http-acceptor-throughput" http-listener="default">
            <param name="batch-delay" value="50"/>
            <param name="direct-deliver" value="false"/>
        </http-acceptor>
        <in-vm-acceptor name="in-vm" server-id="0"/>
        <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
        <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
        <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
        <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
        <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
    </server>
</subsystem>

As for HornetQ, you can use ArtemisMQ also as standalone project. The following tutorial discusses about running an example JMS application on ArtemisMQ.

Capabilities: Beginning with WildFly 10 the application server’s management layer includes a mechanism for allowing different parts of the system to integrate with each other in a loosely coupled manner. This happens thanks to a new component called Capability. To make a capability available, you must package its resources in one or more modules and make them available to the classloading system.
Typically a Capability works out by registering a service with the WildFly’s ServiceContainer, and then dependent capabilities depend on that service. The WildFly Core management layer orchestrates registration of those services and service dependencies by providing a means to discover service names.  Some capabilities are automatically part of a WildFly Core based process, but in most cases the configuration provided by the end user (i.e. in standalone.xml, domain.xml and host.xml) determines what capabilities are present at runtime. 

You can read more about Capabilities on the following github doc: https://github.com/darranl/wildfly-capabilities

Improved ejb subsystem: the ejb pooling configuration has been revamped so that now it includes multiple self­tuning policies applicable to Stateless EJB and to Message Driven Beans.For example, now WildFly now pools stateless session beans by default, using a pool size derived from the size of the IO worker pool. The IO worker pool in turn is computed based on the io system resources You can check it with the following CLI query:

/subsystem=ejb3/strict-max-bean-instance-pool=slsb-strict-max-pool/:read-resource(recursive=false)
 {
  "outcome" => "success",
  "result" => {
  "derive-size" => "from-worker-pools",
  "max-pool-size" => 20,
  "timeout" => 5L,
  "timeout-unit" => "MINUTES"
  }
}

Besides it, an advanced delivery policy (group based) can now be used by Message Driven Beans. See this example:

@MessageDriven(name = "DemoMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue =
"javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue =
"java:/ExampleQueue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-
acknowledge") })
@DeliveryGroup(mygroup)

public class DemoMDB implements MessageListener {
   public void onMessage(Message rcvMessage) {
   . . . .
  }
}

 Having defined the group/s of MDBs then you can activate or deactivate the single group delivery. For example, in order to set to false the delivery of mygroup:

/subsystem=ejb3/mdb-delivery-group=mygroup:write-attribute(name=active,value=false)

Undertow.js

WildFly 10 now supports out of the box the Undertow.js which is designed to make it easy to mix Javascript and Java EE, allowing you to quickly create a front end in Javascript while still using Java EE for all the backend. Undertow.js supports the following features:

– Java EE integration, including dependency injection
– REST
– Templates
– Declarative security
– Filters
– Websockets
– JDBC

The functionality is intended to be used as part of a Servlet deployment. It is designed to make it easy to mix Javascript and Java EE backend functionality, allowing you to quickly create a front end in Javascript while still using Java EE for all the heavy lifting. See the following example:

$undertow
    .onGet("/hello",
        {headers: {"content-type": "text/plain"}},
        [function ($exchange) {
            return "Hello World";
        }])

Accessing the /hello path inside your application returns the text/plain ‘Hello World’ response. 

Migration from legacy subsystems: an automatic CLI­based migration procedure has been added to help users migrate the former legacy systems (jbossweb, messaging, jacorb) into WildFly 10. In order to migrate a legacy subsystem (example “web”), simply add the legacy subsystem configuration in your configuration file and remove the corresponding target subsystem (example “undertow”). Next:

Start WildFly 10 in admin­-only mode:

$ ./standalone.sh --admin-only

Connect from the CLI:

$ ./jboss-cli.sh -c

Now execute the migrate operation in the legacy subsystem. In our case the legacy subsystem is web which will migrate into undertow:

[standalone@localhost:9990 /] /subsystem=web:migrate

Updated Hibernate API

The most relevant change for developers are the following ones:

Full-text search for entities: Offers full-text search support for objects stored by Hibernate ORM, Infinispan and other sources so that you can achieve search words with text, order results by relevance and find by approximation (fuzzy search)

Cluster-friendly: Hibernate Search offers several easy to setup clustering strategies including master / slaves definition, JMS / JGroups replication, Infinispan distributed index

Faceting and geolocation: Entities can now be tagged with the annotation @Spatial. You can filter results around a certain location like the user position.

References:
http://hibernate.org/search/
https://github.com/undertow-io/undertow-docs/blob/master/src/main/asciidoc/undertow-js.asciidoc#undertowjs

Found the article helpful? if so please follow us on Socials