WildFly 12.0.0.Beta1 tagged and available

WildFly 12.0.0.Beta1 has been tagged and has been (I think) officially released. The announcement happened a few days back in the dev mailing list and unlike the previous releases, this time the release binaries seem to be only available in Maven repository and can be obtained from here - WildFly 12.0.0.Beta1 distribution (the .tar.gz and .zip are the relevant ones). The list of changes for this release can be found in the JIRA release notes.

As you'll notice in the release notes, there's some initial support for EE 8 specs, including Servlet 4.0 among others. Plus there's also numerous bug fixes in this release from the previous 11.0.0.Final version which was released some months back. As usual, please give this version a try and if there are any issues or feedback that you would like to report, please start a discussion in the WildFly user forum

If you haven't been following the WildFly dev mailing list, there's also a discussion which outlines the release plans for WildFly going forward. You can find that discussion here

Finally, there's been major changes to Java EE processes and committee and even the name, over the past year. If you haven't been following those changes, then you can read through Mark Little's recent blogs including the most recent ones which talk about the new brand name for Java EE  and setting up of the working group.

Remote JMX access to WildFly (or JBoss AS7) using JConsole

One of the goals of JBoss AS7 was to make it much more secure by default, when compared to previous versions. One of the areas which was directly impacted by this goal was that you could no longer expect the server to expose some service on a port and get access to it without any authentication/authorization. Remember that in previous versions of JBoss AS you could access the JNDI port, the JMX port without any authentication/authorization, as long as those ports were opened for communication remotely. Finer grained authorizations on such ports for communications, in JBoss AS7, allows the server to control who gets to invoke operations over that port.

Of course, this is not just limited to JBoss AS7 but continues to be the goal in WildFly (which is the rename of JBoss Application Server). In fact, WildFly has gone one step further and now has the feature of "one single port" for all communication.

JMX communication in JBoss AS7 and WildFly

With that background, we'll now focus on JMX communication in JBoss AS7 and WildFly. I'll use WildFly (8.2.0 Final) as a reference for the rest of this article, but the same details apply (with minor changes) to other major versions of JBoss AS7 and WildFly, that have been released till date.

WildFly server is composed of "subsystems", each of which expose a particular set of functionality. For example, there's the EE subsystem which supports the Java EE feature set. Then there's the Undertow subsystem which supports web/HTTP server functionality. Similarly, there's a JMX subsystem which exposes the JMX feature set on the server. As you all are aware, I'm sure, JMX service is standardly used for monitoring and even managing Java servers and this includes managing the servers remotely. The JMX subsystem in WildFly allows remote access to the JMX service and port 9990 is what is used for that remote JMX communication.

JConsole for remote JMX access against JBoss AS7 and WildFly

Java (JDK) comes bundled with the JConsole tool which allows connecting to local or remote Java runtimes which expose the JMX service. The tool is easy to use, all you have to do is run the jconsole command it will show up a graphical menu listing any local Java processes and also an option to specify a remote URL to connect to a remote process:

# Start the JConsole
$JAVA_HOME/bin/jconsole

Let's assume that you have started WildFly standalone server, locally. Now when you start the jconsole, you'll notice that the WildFly Java process is listed in the local running processes to which you can connect to. When you select the WildFly Java instance, you'll be auto connected to it and you'll notice MBeans that are exposed by the server. However, in the context of this article, this "local process" mode in JConsole isn't what we are interested in.

Let's use the "Remote process" option in that JConsole menu which allows you to specify the remote URL to connect to the Java runtime and username and password to use to connect to that instance. Even though our WildFly server is running locally, we can use this "Remote process" option to try and connect to it. So let's try it out. Before that though, let's consider a the following few points:

1. Remember that the JMX subsystem in WildFly allows remote access on port 9990
2. For remote access to JMX, the URL is of the format - service:jmx:[vendor-specific-protocol]://[host]:[port]. The vendor specific protocol is the interesting bit here. In the case of WildFly that vendor-specific-protocol is http-remoting-jmx.
3. Remember that WildFly is secure by default which means that just because the JMX subsystem exposes 9990 port for remote communication, it doesn't mean it's open for communication to anyone. In order to be allowed to communicate over this port, the caller client is expected to be authenticated and authorized. This is backed by the "ManagementRealm" in WildFly. Users authenticated and authorized against this realm are allowed access to that port.

Keeping those points in mind, let's first create a user in the Management Realm. This can be done using the add-user command line script (which is present in JBOSS_HOME/bin folder). I won't go into the details of that since there's enough documentation for that. Let's just assume that I created a user named "wflyadmin" with an appropriate password in the Management Realm. To verify that the user has been properly created, in the right realm, let's access the WildFly admin console at the URL http://localhost:9990/console. You'll be asked for username and password for access. Use the same username and password of the newly created user. If the login works, then you are good. If not, then make sure you have done things right while adding the new user (as I said I won't go into the details of adding a new user since it's going to just stretch this article unnecessarily long).

So at this point we have created a user named "wflyadmin" belonging to ManagementRealm. We'll be using this same user account for accessing the JMX service on WildFly, through JConsole. So let's now bring up the jconsole as usual:

$JAVA_HOME/bin/jconsole

On the JConsole menu let's again select the "Remote process" option and use the following URL in the URL text box:

service:jmx:http-remoting-jmx://localhost:9990

Note: For JBoss AS 7.x and JBoss EAP 6.x, the vendor specific protocol is remoting-jmx and the port for communication is 9999. So the URL will be service:jmx:remoting-jmx://localhost:9999

In the username and password textboxes, use the same user/pass that you newly created. Finally, click on Connect. What do you see? It doesn't work! The connection fails. So what went wrong?

Why isn't the JConsole remote access to WildFly not working?

You did all the obvious things necessary to access the WildFly JMX service remotely but you keep seeing that JConsole can't connect to it. What could be the reason? Remember, in one of those points earlier, I noted that the "vendor specific protocol" is an interesting bit? We use http-remoting-jmx and that protocol internally relies on certain WildFly/JBoss specific libraries, primarily for remote communication and authentication and authorization. These libraries are WildFly server specific and hence aren't part of the standard Java runtime environment. When you start jconsole, it uses a standard classpath which just has the relevant libraries that are part of the JDK/JRE.

To solve this problem, what you need to do is bring in the WildFly server specific libraries into the classpath of JConsole. Before looking into how to do that, let's see which are the WildFly specific libraries that are needed. All the necessary classes for this to work are part of the jboss-cli-client.jar which is present in JBOSS_HOME/bin/client/ folder. So all we need to do in include this jar in the classpath of the jconsole tool. To do that we use the -J option of jconsole tool which allows passing parameters to the Java runtime of jconsole. The command to do that is:

$JAVA_HOME/bin/jconsole -J-Djava.class.path=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/jconsole.jar:/opt/wildfly-8.2.0.Final/bin/client/jboss-cli-client.jar

(Note that for Windows the classpath separator is the semi-colon character instead of the colon)

Note, the server specific jar for JBoss AS 7.x and JBoss EAP 6.x is named jboss-client.jar and is present at the same JBOSS_HOME/bin/client directory location.

So we are passing -Djava.class.path as the parameter to the jconsole Java runtime, using the -J option. Notice that we have specified more than just our server specific jar in that classpath. That's because, using the -Djava.class.path is expected to contain the complete classpath.  We are including the jars from the Java JDK lib folder that are necessary for JConsole and also our server specific jar in that classpath.

Running that command should bring up JConsole as usual and let's go ahead and select the "Remote process" option and specify the same URL as before:

service:jmx:http-remoting-jmx://localhost:9990

and the same username and password as before and click Connect. This time you should be able to connect and should start seeing the MBeans and others services exposed over JMX.

How about providing a script which does this necessary classpath setup?

Since it's a common thing to try and use JConsole for remote access against WildFly, it's reasonable to expect to have a script which sets up the classpath (as above) and you could then just use that script. That's why WildFly ships such a script. It's in the JBOSS_HOME/bin folder and is called jconsole.sh (and jconsole.bat for Windows). This is just a wrapper script which internally invokes the jconsole tool present in Java JDK, after setting up the classpath appropriately. All you have to do is run:

$JBOSS_HOME/bin/jconsole.sh

What about using JConsole from a really remote machine, against WildFly?

So far we were using the jconsole tool that was present on the same machine as the WildFly instance, which meant that we have filesystem access to the WildFly server specific jars present in the WildFly installation directory on the filesystem. This allowed us to setup the classpath for jconsole to point to the jar on the local filesystem?

What if you wanted to run jconsole from a remote machine against a WildFly server which is installed and running on a different machine. In that case, your remote client machine won't be having filesystem access to the WildFly installation directory. So to get jconsole running in such a scenario, you will have to copy over the JBOSS_HOME/bin/jboss-cli-client.jar to your remote client machine, to a directory of your choice and then setup the classpath for jconsole tool as explained earlier and point it to that jar location. That should get you access to JMX services of WildFly from jconsole on a remote machine.

 

More questions?

If you still have problems getting this to work or have other questions, please start a discussion in the JBoss community forums here https://developer.jboss.org/en/wildfly/content.

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 http://wildfly.org/downloads/. 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 http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/. 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 https://issues.jboss.org/browse/WFLY-3102. 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 https://developer.jboss.org/thread/250375 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.

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 http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001458.html.

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.

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 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 jboss-ejb-client.properties that's used to invoke EJBs. Earlier, you probably had:

 
remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication
remote.connection.default.port=4447

(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:

 
remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication (the HTTP port)
remote.connection.default.port=8080

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.

[WildFly Home] [WildFly JIRA] [WildFly User Forum] [WildFly downloads] [WildFly nightly builds]

WildFly community members nominated for JBoss Community Recognition Award - voting open

Every year, JBoss community members are rewarded for their work in the community as part of the JBoss Community Recognition Awards (JBCRA). This year we have 2 community members from the WildFly project (previously known as JBoss Application Server) who have been nominated in 3 different categories.

Nicklas Karlsson has been nominated in the Issue/JIRA category and Stephen Coy has been nominated in 2 categories - Community Leadership and New Features. Please do vote for them here https://www.jboss.org/jbcra/vote.html - it's just one page and takes less than a minute to vote. It's one way of thanking them for the help they have been providing in the community. Remember that these nominees are volunteers and are not Red Hat/JBoss employees so their contributions are that much more valuable.

The voting ends on July 26 2013. Don't wait for that date, vote now! :)

WildFly 8.0.0.Alpha1 release and a bit of history

It's been around 2 weeks now since we released WildFly 8.0.0.Alpha1 version. The download is available on the WildFly downloads page. I'm sure many of you might be wondering what WildFly is and some of you who are aware of what it is, might not be aware that there has been a release. I'll try and answer some of these questions and also add some details about what this release contains.

So what's WildFly?

WildFly is the new name for the community project which was previously known as JBoss Application Server. Late in 2012, we decided that we had to rename the community project, JBoss Application Server, to something else. As part of that (long drawn out) process, community members were asked to suggest new names and a few selected names were voted to select the new name. Ultimately, WildFly turned out to be the winner.

Why did we change the name?

JBoss Application Server (both the name and the project) has been a very popular project over the years. Initially when it started off, it was known simply as JBoss. Anytime anyone referred to the name JBoss, people knew that they were talking about the JBoss Application Server community edition. Over the years though, the reference started to get hazy. The community edition JBoss Application Server also has a paid and fully supported version known as JBoss Enterprise Application Platform (JBoss EAP). Notice the "JBoss" name in there? So there's JBoss Application Server community edition and then there's JBoss EAP paid version. It did not stop there! Over the years, various community projects hosted at jboss.org started naming their projects with the name "JBoss" in it. So there was "JBoss ESB", "JBoss Transactions", "JBoss Messaging" and many such projects with the name "JBoss" in it. It's certainly no fault of those projects that they used "JBoss" as part of the name. It did make sense to use that name, since those projects were developed by JBoss community members. By the way, did you just notice the name "JBoss" even means a reference to the JBoss community as a whole?

So I guess at this point you might have realized where I'm headed with all this historical evidence. Clearly, the name "JBoss" had started to mean much more than just the JBoss Application Server community project. Although it was good thing from a brand point of view, it clearly wasn't too good from various other aspects. We had started seeing too much confusion about what each project/product stood for not just from a name point of view but also a release roadmap point of view. Take for example JBoss Application Server and JBoss EAP - users, typically those who are more busy with their application (rightly so) than trying to understand what each variant of project/product with the name "JBoss" in it meant, were just not sure which one to pick and which release of those had what features in it. Of course, it would take some explanation to help them understand this, but doing this on a regular basis was a clear sign that this isn't the right way forward.

So slowly during the past few years, there has been a conscious decision not to name new projects with "JBoss" in its name and also to rename some of the existing projects wherever possible. So for example, when "JBoss Messaging" project decided to release a completely new and better version, the project decided to name it "HornetQ". Similarly, JBoss Transactions is now known as Narayana. There are various examples of such renames and new names. Obviously, doing the same for JBoss Application Server would need some time and extra efforts since it was a really huge change for various reasons. But it had to be done ultimately and that's why it's now WildFly.

So what happens to the "JBoss" name in JBoss EAP?

The rename is only for the JBoss Application Server community edition. The paid version is still named JBoss Enterprise Application Platform (JBoss EAP). Since one of the original intentions of the rename was to clear the confusion between JBoss Application Server community edition and similar named JBoss EAP, the name change only applies to the community edition. So ultimately, over time, when someone refers to WildFly, we clearly know they are talking about the community project and very specifically the application server project.

How does WildFly 8.0.0.Alpha1 release relate to the previous JBoss AS7 releases?

WildFly 8.0.0.Alpha1 is the continuation of the release cycle of the application server community edition, which was previously known as JBoss AS7. The last release of JBoss AS7 was 7.1.1.Final (way back in March 2012) and WildFly 8.0.0.Alpha1 is now the next release of the same project with the new name.

Is WildFly 8.0.0.Alpha1 a release of a new project?

I know I already answered a variant of this question earlier, but I wanted to include the answer to this differently worded question too since I wanted it to be very clear that WildFly is just a rename of JBoss Application Server. It is not a new project. So WildFly 8.0.0.Alpha1 release is the continuation of the release cycle of the previously named JBoss Application Server project.

What's new in 8.0.0.Alpha1 release?

Now that we have addressed what WildFly is and a history around the name change, let's focus on the release itself. Some time back, Jason, the project lead of WildFly, listed down the goals of WildFly 8 release in the 2 dev mailing list threads here:

WildFly 8 roadmap (proposal) - http://lists.jboss.org/pipermail/jboss-as7-dev/2013-March/007884.html

WildFly 8 Schedule - http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000062.html

So those are the goals and the schedule for WildFly 8.

WildFly 8.0.0.Alpha1 is the first milestone towards that. The release contains some of the new Java EE7 features, a new web server implementation named Undertow (as a replacement to JBossWeb web server) and some other new features. Of course, it also contains numerous bug fixes and since the previous release was more than a year back, the number of bug fixes are huge. Jason has summarized the WildFly 8.0.0.Alpha1 release in the dev mailing thread here http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000139.html.

Please download this new version and give it a try. Like always, any feedback, questions or asking for help is always welcome in our WildFly user forums.

What's next for WildFly?

Like Jason noted in the WildFly 8 release schedule thread, we plan to push out a release almost every other month with the goal of having a 8.0.0.Final version at the end of this year. So, like with all the help that the community provided during AS7 releases:

Community help for JBoss AS 7.0 release - https://community.jboss.org/thread/169491
Community help for JBoss AS 7.1 release - https://community.jboss.org/thread/195430

please continue to do the same for WildFly releases.

In the coming weeks/months, we plan to blog more about the WildFly releases and the technologies that the WildFly runtime supports. In fact, Jason has asked in this dev mailing list thread http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000144.html whether the community members will be willing to blog too. That's another way of contributing too. So if you have any blogs that you have written or plan to write on WildFly, do let us know about it in that thread.

Those of you who want to try out the nightly builds of WildFly, can get it from our continuous integration job mentioned here https://community.jboss.org/thread/224262.

By the way, what's that image at the beginning of this article?

Thanks for noticing! That's the logo for WildFly which the jboss.org team of artists (yeah, we do have team for that) helped us come up with :) Like it?

[WildFly Home] [WildFly JIRA] [WildFly User Forum] [WildFly downloads] [WildFly nightly builds]

Java EE 7 and EJB 3.2 support in JBoss AS 8

 Update (June 10 2013): JBoss AS is now known as WildFly. This post was written before WildFly 8.0.0.Alpha1 was released. Any references to JBoss AS8 in this article should be considered as a reference to WildFly 8. Read my next article here http://jaitechwriteups.blogspot.in/2013/06/wildfly-release-and-history-behind-the-release.html which explains what WildFly is and why JBoss AS was renamed to WildFly.

Some of you might be aware that the Public Final Draft version of Java EE 7 spec has been released. Among various other new things, this version of Java EE, brings in EJB 3.2 version of the EJB specification. EJB 3.2 has some new features compared to the EJB 3.1 spec. I'm quoting here the text present in the EJB 3.2 spec summarizing what's new:

The Enterprise JavaBeans 3.2 architecture extends Enterprise JavaBeans to include the following new functionality and simplifications to the earlier EJB APIs:

• Support for the following features has been made optional in this release and their description is moved to a separate EJB Optional Features document:
• EJB 2.1 and earlier Entity Bean Component Contract for Container-Managed Persistence
• EJB 2.1 and earlier Entity Bean Component Contract for Bean-Managed Persistence
• Client View of an EJB 2.1 and earlier Entity Bean
• EJB QL: Query Language for Container-Managed Persistence Query Methods
• JAX-RPC Based Web Service Endpoints
• JAX-RPC Web Service Client View


• Added support for local asynchronous session bean invocations and non-persistent EJB Timer Service to EJB 3.2 Lite.


• Removed restriction on obtaining the current class loader; replaced ‘must not’ with ‘should exercise caution’ when using the Java I/O package.


• Added an option for the lifecycle callback interceptor methods of stateful session beans to be executed in a transaction context determined by the lifecycle callback method's transaction attribute.


• Added an option to disable passivation of stateful session beans.


• Extended the TimerService API to query all active timers in the same EJB module.


• Removed restrictions on javax.ejb.Timer and javax.ejb.TimerHandle references to be used only inside a bean.


• Relaxed default rules for designating implemented interfaces for a session bean as local or as remote business interfaces.


• Enhanced the list of standard activation properties.


• Enhanced embeddable EJBContainer by implementing AutoClosable interface.

As can be seen, some of the changes proposed are minor. But there are some which are useful major changes. We'll have a look at a couple of such changes in this article.

1) New API TimerService.getAllTimers()

EJB 3.2 version introduces a new method on the javax.ejb.TimerService interface, named getAllTimers. Previously the TimerService interface had (and still has) a getTimers method. The getTimers method was expected to return the active timers that are applicable for the bean on whose TimerService, the method had been invoked (remember: there's one TimerService per EJB).

In this new EJB 3.2 version, the newly added getAllTimers() method is expected to return all the active timers that are applicable to *all beans within the same EJB module*. Typically, an EJB module corresponds to a EJB jar, but it could also be a .war deployment if the EJBs are packaged within the .war. This new getAllTimers() method is a convenience API for user applications which need to find all the active timers within the EJB module to which that bean belongs.

2) Ability to disable passivation of stateful beans

Those familiar with EJBs will know that the EJB container provides passivation (storing the state of the stateful bean to some secondary store) and activation (loading the saved state of the stateful bean) capability to stateful beans. However, previous EJB versions didn't have a portable way of disabling passivation of stateful beans, if the user application desired to do that. The new EJB 3.2 version introduces a way where the user application can decide whether the stateful bean can be passivated or not.

By default, the stateful bean is considered to be "passivation capable" (like older versions of EJB). However, if the user wants to disable passivation support for certain stateful bean, then the user has the option to either disable it via annotation or via the ejb-jar.xml deployment descriptor.

Doing it the annotation way is as simple as setting the passivationCapable attribute on the @javax.ejb.Stateful annotation to false. Something like:

 @javax.ejb.Stateful(passivationCapable=false) // the passivationCapable attribute takes a boolean value  
 public class MyStatefulBean {  
 ....  
 }  

Doing it in the ejb-jar.xml is as follows:

 <?xml version="1.0" encoding="UTF-8"?>  
 <ejb-jar xmlns="http://xmlns.jcp.org/xml/ns/javaee"  
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee  
      http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd"  
      version="3.2">  
   <enterprise-beans>  
     <session>  
       <ejb-name>foo-bar-bean</ejb-name>  
       <ejb-class>org.myapp.FooBarStatefulBean</ejb-class>  
       <session-type>Stateful</session-type>  
       <!-- passivation-capable element takes either a true or a false value -->  
       <passivation-capable>false</passivation-capable>  
     </session>  
     ...  
   </enterprise-beans>  
 </ejb-jar>  

Two important things to note in that ejb-jar.xml are the version=3.2 attribute (along with the http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd schema location) on the ejb-jar root element and the passivation-capable element under the session element.

So, using either of these approaches will allow you to disable passivation on stateful beans, if you want to do so.

Java EE 7 and EJB 3.2 support in JBoss AS8:

JBoss AS8 has been adding support for Java EE 7 since the Public Final Draft version of the spec has been announced. Support for EJB 3.2 is already added and made available. Some other Java EE 7 changes have also made it to the latest JBoss AS 8 builds. To keep track of the Java EE 7 changes in JBoss AS8, keep an eye on this JIRA https://issues.jboss.org/browse/AS7-6553.

To use the already implemented features of Java EE 7 in general or EJB 3.2 in particular, you can download the latest nightly build/binary of JBoss AS from here. Give it a try and let us know how it goes. For any feedback, questions or if you run into any kind of issues, feel free to open a discussion thread in our user forum here.

[JBoss AS Home] [JBoss AS JIRA] [JBoss AS User Forum] [JBoss AS downloads] [JBoss AS nightly builds]