Saturday, June 22, 2013

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! :)

Monday, June 03, 2013

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 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?

Tuesday, March 26, 2013

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.