JBoss = WildFly, OK?
WildFly 8 versus TomEE versus WebLogic, and other matters
“Jboss = WildFly? Why the different name?” asked one Redditor, responding to linked press release about the launch of WildFly 8. Ironically, the point of the rebranding is part of an effort on the side of RedHat to reduce this confusion. We at JAXenter have noticed a few similar responses to our own WildFly news, so we thought we’d grab Jason Greene, WildFly 8 Architect, and find out how the community at large is adjusting. While we were at it, also wanted to find out how the team thinks their software stands up against its biggest rivals, and what the biggest changes are in the latest incarnation of the community app server.
JAX: Now that GlassFish is lacking commercial support, there are several contenders for companies looking for an alternative - how would you say they compare to WildFly 8.0?
Greene: WildFly and TomEE are both open-source, light-weight and developer friendly. WebLogic, on the other hand, is proprietary and heavy-weight. It’s our belief that open-source is essential for an application server because it is so tightly coupled with your application.
The big difference between TomEE and WildFly is that WildFly offers a great deal more features
If you are debugging your application it is invaluable to be able to look under the hood, and see what is happening. Developer friendliness is also important because it has a direct impact on a development team’s productivity.
The big difference between TomEE and WildFly is that WildFly offers a great deal more features. WildFly includes the full Java EE platform, whereas TomEE just provides the Web Profile. WildFly offers advanced administrative and operations capabilities, whereas TomEE is just focused on providing an application runtime. That said, not providing these additional capabilities means that TomEE is able to offer a very slim disk footprint.
What do you think are the key features of this release?
The biggest feature everyone has been waiting for is Java EE7 support. Although it’s not just about features, I think everyone is excited to see our first community final release after the big WildFly/JBoss EAP split. This release is somewhat special in that the community was involved in every step along the way, including naming the project.
On the subject of the big name switch - do you think people are still confused about the change?
I think now that we have gone through a full release cycle, and put up a lot of resources about the project, that the impacts of the project and product split are quite a bit clearer. That said, everyone won’t be completely adjusted until they have been using the new project for a while.
What are the most significant changes?
This is a large release with a number of changes. The most significant feature is that WildFly 8 is Java EE7 certified, meeting both the full and Web Profiles. Java EE7 improves developer productivity and provides a rich set of APIs and capabilities that make meeting the technical demands applications face easier than ever.
Another important change is that WildFly 8 includes a new lightweight, highly performant and scalable web server called Undertow. Undertow supports both non-blocking and blocking styles of web development, as well as the latest standards such as Web Sockets. It is also a highly customizable and flexible server with the ability to handle everything from dynamic routing to custom protocols. In addition, it can function as an efficient reverse proxy or file server, removing the need to use a traditional native web server in your environment.
The most significant feature is that WildFly 8 is Java EE7 certified, meeting both the full and Web Profiles
Also noteworthy is that WildFly 8 includes a number of operational improvements. The management API and administration console now support role-based access control (RBAC), as well as auditing via a new audit log facility. These capabilities enable an organization to segment administrative and operational responsibilities across different users and teams.
Finally, WildFly 8 has added the infrastructure to support patching. Future releases will provide an additional patch option for our users to download.
Is there anything you think people will struggle with in updating to or transitioning from other servers to WildFly 8.0, and if so, are there any resources you can recommend to help them?
Every application server does things a little bit differently, so migrating to WildFly from another vender will require some porting effort. That said, we have already taken steps to make migration easier, and we will continue to do so. As an example, we support a number of different JPA providers. which usually allows someone migrating to reuse the same JPA implementation they were using before.
As to specific resources, two members of our community recently published a useful mini-guide on migrating from Glassfish to WildFly 8 on our blog. Over time I suspect we will build up lots of wikis and guides covering the various types of conversions. In the meantime our forums are a great way to reach out to others, and our community is always very helpful. A number of them have been through migrations and/or are experts in other server platforms as well.
What was the most difficult part about putting 8.0 together? Were there any major challenges?
The biggest challenge was the amount of work we had going on all at the same time. Getting certified on a new major release of the Java EE platform is a big enough challenge on its own, but on top of that we delivered significant management functionality and a new web server. At the same time we also went through a major project rename, and delivered a number of significant JBoss EAP releases as well. It all came together though thanks to the hard work of the talented WildFly contributors.
Have you noticed a significant increase in uptake of WildFly since last November*? (*when Oracle made its announcement about the future of GlassFish)
Yes definitely. We have always been blessed with enthusiastic users, so we have had a lot of interest in all the of 8’s milestone releases. However, a lot of users like to wait until a late Beta or a CR before they try it out. We certainly saw a big increase in interest after we launched CR1, and even more when we announced certification and the final release.