Sunday, December 07, 2014

WildFly 8.2.0.Final release - Quick overview of the changes

It's been a while since I last wrote on this blog. Although I have had some topics that I wanted to blog about, I just haven't found enough time to do it. I finally decided to write this up today after I saw a mail from one of the JBoss community members, checking up on why there haven't been any updates here lately (thanks for checking, Bhaskar! :)).

Before I move on to some technical things, a quick personal update - It's now been more than a year now since I changed jobs. I no longer work at Red Hat, JBoss. My (almost) 5 years at JBoss have been very fruitful and I enjoyed being part of the (JBoss AS/WildFly) application server development team. Last year, I decided to move on to something different and the right opportunity came along and I decided to take it up. Some of you know that I've been involved with the JBoss community for longer than the 5 years that I had been employed at Red Hat. I have been a JBoss community member since around 2004/2005, so even though I have moved on from Red Hat, I am still active in the JBoss forums.

Now that you all know what I've been upto, let's move on to some technical things.

WildFly 8.2.0.Final released!

The WildFly team just released the 8.2.0.Final version of WildFly some days back. As usual, it's available for download on the project's download page This is mainly a bug fix (plus some features) release in the 8.x series. I for one, was pleased to see this release happen because it allows the community to receive bug fixes on top of 8.1.0.Final release, which has been tested/used in the community for quite some time now. The WildFly team has indicated that this will be the last release in the 8.x series which sounds reasonable, given that the development team has already moved on to work on the 9.x series. It's never easy to work/maintain more than one major version of the code, especially in the context of bug fixes and backward compatibility.

What does WildFly 8.2.0.Final contain?

The complete overview of changes in available in this announcement on Jason's blog CDI spec upgrade and improved WebSocket support are the main items in terms of feature set. There's also this note in the release notes:
- EJBs in WARs now inherit the WAR security domain

There was a recent forum thread, where one of the users asked what that really means. Here's some background to that change As noted in that JIRA, this was feature request that was raised in the context of EJBs packaged in .war deployments. Most of you, I guess, will be aware that Java EE spec allows EJBs to be deployed as part of the .war deployment. What this means is that you can place your EJB classes within the .war/WEB-INF/classes or within a jar in .war/WEB-INF/lib. Although, this sounds straightforward for the end users, there are some technical implications to this (given the way Java EE "components" and "modules" are defined and configured within the server ecosystem). One such detail, is the way one configures the EJBs that are part of the .war deployment. Remember that if this EJB was part of a separate EJB module (within a .jar packaging outside of the .war) then one would use the ejb-jar.xml (and the WildFly specific jboss-ejb3.xml) as the deployment descriptors to configure it. This applies to EJBs deployed in a .war deployment too. i.e. one can use those same files for configuring EJBs. Now since these EJBs are part of a .war, the .war itself can/will have a deployment descriptor if its own (the web.xml and jboss-web.xml).

With that context, consider a case where the you have EJBs within the .war deployment and your .war deployment descriptor (the jboss-web.xml) configures a specific security domain for that deployment. Now remember that the EJBs too can configure a security domain (in jboss-ejb3.xml) and if none is configured and security is enabled on some EJBs, then the default "other" security domain gets used. So let's say your .war deployment, in which the EJBs reside, states that it wants to use "foo-bar" security domain and the EJBs, within that deployment, don't specify any specific security domain. So what should one expect in such scenario? Should the EJBs use the security domain configured at the .war level or should they default to the "other" security domain (since the EJB deployment descriptors don't specify any specific security domain configuration). The previous versions of WildFly had decided to use the default "other" security domain for the EJBs in such a case. Of course, the EJBs could use a jboss-ejb3.xml to set a different security domain, one which matches the jboss-web.xml. So that JIRA which I linked to earlier requested for a better, smarter and a more logical default in such cases. So starting this 8.2.0.Final version of WildFly, if you have a .war containing the EJBs and the EJBs don't define a security domain, then the security domain for any secured EJBs in that deployment *defaults* to the one that's defined at the .war deployment level. If the .war deployment doesn't set any specific security domain, then it ultimately, defaults to the "other" security domain. A good and logical change IMO. This will reduce some of the "surprises" that users have reported with previous version of WildFly, when it came to the security domain usage of EJBs in .war deployments.

For more about this, you can read the discussion here and ask any questions you have around this, in that thread.

What are the other notable things in WildFly 8.2.0.Final?

Although, not specific to 8.2.0.Final, the WildFly release contain a "patch" distribution which you can use if you already are using WildFly 8.1.0.Final and just want to "upgrade" to this new release. WildFly 8 has patch management built in and one can apply this patch on top of an existing 8.1.0.Final version.

What's next for WildFly?

As noted earlier, the WildFly development team has moved on to the next version of the project. Work is now continuing on 9.x version which already has a Alpha version released. So going forward, from what I have read, the releases will happen in the 9.x series.

Wednesday, January 22, 2014

WildFly 8.0 CR1 release and WildFly 8 book

I guess by now everyone is aware that the community JBoss AS server has been renamed to WildFly. The WildFly team has been busy pushing out releases of the 8.0 series during the past few months. It's been a month now since the 8.0 CR1 version of WildFly was released. This is a significant release since the 8.0 CR1 version passes the Java EE7 TCK 100%. The Final version of 8.0 is expected any time soon

Along with this good news about the WildFly 8.0 series nearing the final version, the other good news is that there's now a WildFly 8 administration guide available for purchase. The author of the book is Francesco Marchioni, who in the past has authored books on the JBoss AS series.

Brief review of the WildFly 8 book


The WildFly 8 book by Francesco is aimed at admins and does a good job of covering various administrative configurations for each of the major subsystems that form a part of the WildFly server. The author starts by covering the basics, from installation of the server and goes on to give an overview of the standalone and domain modes of the server. He then goes on to extensively explain each of the major subsystem administration configurations, like the new web subsystem which is backed by Undertow. There's also chapters on EJB and clustering configurations.

Francesco does a good job of covering the major subsystems and also keep the content concise. I found the book to be a good read from an administrator point of view. There are certain tidbits for developers too, but the book is mostly aimed at admins. If you are looking for some book to give you a quick and extensive overview of the subsystems in WildFly, then this is worth it.

Thursday, July 25, 2013

WildFly 8.0.0.Alpha3 released with support for EJB invocations over HTTP

A week back we released WildFly 8.0.0.Alpha3 version. As usual the download is available on WildFly downloads page. This release comes within a month of the 8.0.0.Alpha2 release. Keeping up with the goals of WildFly 8, this new release contains additional EE7 support, certain bug fixes and also some WildFly specific features. The entire release notes are available here.

In this article, I'll provide some details about one of the WildFly features which has made into this release.

WildFly logo

WildFly ports

Traditionally, WildFly and previously named JBoss AS have opened different ports for different protocols and communication. For example, in the JBoss AS7 and now WildFly 8 series, by default the server opens the http port (which is by default 8080), remoting port (which is backed by JBoss Remoting and by default is 4447) and other such ports for usage by the applications deployed on the server. One of the goals of WildFly 8 (Final) is to have one single port open for all types of communication. This is meant to allow admins a better control of the server (firewall rules for example).

HTTP Upgrade support in Undertow

As some of you might know by now, the WildFly 8 series now uses Undertow as its web container. Undertow supports a standard feature called HTTP Upgrade. As can be read in that RFC, this feature allows the HTTP protocol to switch to a different protcol based on the presence of a header in the protocol data. This HTTP Upgrade feature acts as the backbone of the proposed "single port for communication" feature in WildFly.

EJB invocation over HTTP

Now that we have some background on HTTP Upgrade, let get to the details about the new feature that WildFly 8.0.0.Alpha3 introduces. Up until WildFly 8.0.0.Alpha2 (and previously in JBoss AS7 series) a project called JBoss Remoting has been the underlying protocol for remote communication with the server. The communication by default used to happen on the port 4447. Many of you will be familiar with this port, since this is what you used while looking up EJBs from a remote client.

Starting WildFly 8.0.0.Alpha3 (i.e. this new release), this port is no longer opened by WildFly by default. So how does one invoke EJBs or even use remote-naming (which too used this port) starting this version? The answer is simple, these remote clients will now have to use the HTTP port which by default is port 8080. The rest of the code will remain the same. This HTTP port is managed by the Undertow server which like I said earlier, has support for HTTP Upgrade. Internally, the EJB client API project (which is JBoss specific project dealing with remote EJB invocations) does the necessary plumbing to request Undertow to switch to JBoss "remoting" protocol while communicating on that HTTP port. Undertow then switches the protocol to "remoting" and the rest of the communication transparently happens as if it was the usual invocation on the remoting port.

So let's see some code to understand what exactly changes from previous version to the new version, from a remote client point of view. Let's take the example of the that's used to invoke EJBs. Earlier, you probably had:


# the server hostname/IP

# the port for communication

(and some other properties)

Starting this release, the only thing that changes is the port number in that properties, rest of it remains the same. So:


# the server hostname/IP

# the port for communication (the HTTP port)

So that's it from a typical client point of view.

For other new features and bug fixes, please take a look at the release notes.