Java EE Articles

New Course on Changes in Java EE 6 and WebSphere 8.0 Posted

I’ve posted a new course which covers some of the changes in Java EE 6 and WebSphere 8.0.  WA2084 What’s New in WebSphere 8.0 and Java EE 6 will be a one day lecture-only class covering the following:

  • Changes in Java EE 6
  • Changes in JSF 2.0
  • Overview of Contexts and Dependency Injection (CDI)
  • What’s New in WebSphere Application Server 8.0
  • WebSphere installation with Installation Manager
  • WebSphere 8.0 HPEL logging

The idea is to cover an overview of all of the changes introduced in Java EE 6 and WebSphere 8.0 followed by more detail on some of the major areas of change.

I think this class will be a good overview for clients to quickly know what changes exist and how they may impact their own projects and WebSphere environments.  This class might be great to take early in the migration process with perhaps more detailed training, like our WebSphere Application Server 8.0 Administration and WebSphere Application Server 8.0 Programming courses to come later.

If you have any question about this or any other training class please contact us and we would be happy to help!

No Comments

Using jQuery With JSF 2.0

Today, I had to finally use both technologies in the same project. You need to do a few things for jQuery to work with JSF 2.0.

  1. Assign ID for all relevant UI components and their parents. Only then can you be sure about the DOM element ID of the component you are trying to manipulate.
  2. Escape the ":" character in the ID.

Let’s learn these two principles using an example. Let’s say, that we have a text box in a form. Make sure both have an ID.

<h:form id="form">
    <h:inputText size="20" value="#{ctrl.dateAsString}" id="dateOfExpense"/>

This means, the text box will have an ID of form:dateOfExpense. If your form has a complicated hierarchy, you can always look at the ID by viewing the source of the page rendered by JSF.

Unfortunately, the ":" character causes havoc in jQuery API. We need to protect it using two back slashes. So, to refer to the text box, we should use the selector "#form\\:dateOfExpense". For example, to convert the text box to a jQuery UI date picker, we will do this.

<link type="text/css" href="css/ui-lightness/jquery-ui-1.8.21.custom.css" rel="stylesheet" />
<script type="text/javascript" src="scripts/jquery-1.7.2.min.js"></script>
<script type="text/javascript" src="scripts/jquery-ui-1.8.21.custom.min.js"></script>

<script type="text/javascript">


Understanding JSF View Parameters

JSF 2.0 adds support for view parameters. This, essentially adds some support for GET request making it possible to bookmark some of the pages. This feature was sorely lacking in JSF 1.x and is much welcomed by the development community. However, I was surprised by the lack of any good tutorial showing any real life use of the feature.

Primary use of a bookmarkable dynamic page is to lookup some data. The identifier of the data is provided in the URL parameters. For example:

  • /TrackOrderStatus?orderId=1029
  • /FindCustomer?id=1928

This wasn’t possible in JSF 1.x. For developers who already know JSF 1.x, view parameters are best learned by migrating an existing application.

Let’s say that we have a simple customer lookup application. We will first build it the old way that uses POST request.

The Customer class is as follows.

public class Customer {
	String id;
	String name;
	public Customer(String id, String name) { = id; = name;
	public Customer() {
	public String getId() {
		return id;
	public void setId(String id) { = id;
	public String getName() {
		return name;
	public void setName(String name) { = name;

The CustomerDAO class looks like this with a dummy in-memory database.

public class CustomerDAO {
	static HashMap<String, Customer> data;
	static {
		data = new HashMap<String, Customer>();
		data.put("E001", new Customer("E001", "Bugs Bunny"));
		data.put("E002", new Customer("E002", "Daffy Duck"));
		data.put("E003", new Customer("E003", "Samity Sam"));
	public Customer findCustomer(String id) {
		return data.get(id);

Finally, the JSF managed bean looks like this.

public class MainController {
	String lookupId;
	Customer customer = new Customer();
	public String getLookupId() {
		return lookupId;
	public void setLookupId(String lookupId) {
		this.lookupId = lookupId;
	public Customer getCustomer() {
		return customer;
	public void setCustomer(Customer customer) {
		this.customer = customer;
	public String doLookup() {
		CustomerDAO dao = new CustomerDAO();
		customer = dao.findCustomer(lookupId);
		return "result";

Now, we can get to the page design. The index.xhtml page has a form where user can type in a customer ID and perform a lookup.

<!DOCTYPE html>
<html xmlns=""
	Search customer by id:<br />
		<h:inputText value="#{mainController.lookupId}"/><br />
		<h:commandButton type="submit" value="Submit"
			action="#{mainController.doLookup}" />

The result.xhtml page looks like this. Note: JSF 1.x developers pay attention. The doLookup() method returns an outcome of "result". In absence of any matching navigation rule, JSF 2.0 will navigate to result.xhtml.

<!DOCTYPE html>
<html xmlns=""

		<b>Name:</b> ${}

This is pretty straightforward and works almost the same way as things did in JSF 1.0 (except there is no need for faces-config.xml for a simple app like this). After you deploy the application, you can execute index.xhtml.


Enter a valid id and click Submit. You should see the result.


So far so good. Except, we are using POST request and the result page can’t be book marked. How can we migrate that to use GET? The answer is view parameters. This will need a change in the result.xhtml page. We need to do two things:

  1. Map URL parameters in a GET request to managed bean properties.
  2. Have the action method doLookup() invoked so that we can populate the Customer bean.

Open result.xhtml in editor. Between the head and body tags, define the view parameter:


	<f:viewParam name="id" value="#{mainController.lookupId}" />
	<f:event listener="#{mainController.doLookup}" 

		<b>Name:</b> ${}

There are many things going on here:

  1. <f:viewParam> must appear within <f:metadata>.
  2. <f:metadata> must appear directly under the view root. That is, you can not define it within <h:head> or <h:body>.
  3. The name attribute of <f:viewParam> defines the name of the URL parameter. This value is set to the property identified by the value attribute. That means, in our case, the id URL parameter will be set as the lookupId property of MainController.
  4. The <f:event> tag is used to have the action handler method invoked when a GET request arrives for result.xml.

After you deploy the application, you should be able to execute the result page directly by supplying the id URL parameter. For example: http://localhost:9080/JSFTest/result.faces?id=E001. Depending on the URI path binding of the JSF servlet, it can also be: http://localhost:9080/JSFTest/faces/result.xhtml?id=E001.

You can put hyperlinks in your application using <h:link outcome="result?id=E001">Bugs</h:link>.

There is a slight problem at this point. If you submit the original form, doLookup() will be called twice – first time due the POST request and next time due to the <f:event> tag in result.xhtml. The solution is to change the action of the commandButton to an outcome, rather than an action handler method. Open index.xhtml and change the action of the commandButton to "result" outcome.

<h:form styleClass="form" id="form1">
Search customer by id:<br />
	<h:inputText value="#{mainController.lookupId}"></h:inputText>
	<br />
	<h:commandButton type="submit" value="Submit"
		action="result" />

No Comments

Goodbye Tomcat!

Tomcat has been a very popular alternative to other application servers like JBoss, WebLogic and WebSphere. People preferred it for its simplicity. I am writing this article to point out how Java EE 6 changes things and why using tomcat could be downright harmful.

Let’s have a quick summary of what makes Java EE 6 so great:

  • Contexts and Dependency Injection (CDI).
  • Java Server Faces (JSF) 2.0.
  • No interface EJB and ability to create EJB in a web module.
  • RESTful Web Service using JAX-RS.

There is the problem with Tomcat right there. None of the above technologies are supported by Tomcat out of the box. Surely, you can add enough JAR files to your web project to get CDI, JSF and JAX-RS. After you are done doing that, you have pretty much created a JBoss look alike. Even then, CDI will be semi-functional. CDI really needs a proper Java EE web and EJB container.

Finally, lack of EJB remains a huge elephant in the room. Sure, EJB was complicated and over engineered. There were good reasons to shun it. That’s not the case any more. EJB has been simplified to the extent it is downright criminal not to use session EJB as your façade to the model layer.

EJB buys you several valuable architecture attributes:

  • You get automated transaction management.
  • You get role based security.
  • Doing audit logging from the model layer becomes a breeze (since you know the user Principal).
  • @Startup and @Singleton classes for better application initialization.
  • Stateless session EJBs can be directly exposed as RESTful Web Services, there by creating a fully transactional and secure interface. With JAX-RS, you can secure a POJOs resource but don’t get transaction support.

All it takes is one extra line to create an EJB:

@Stateless //No interface local EJB
public class OrderManager {


You can even create these EJBs right within your web module. There is no excuse not to use them.

Edited: Apache TomEE project has assembled these missing pieces and integrated them with Tomcat. This is the correct direction for the Tomcat project. My problem with Tomcat is that most shops that will use it will shy away from what is so great about Java EE 6. Don’t do that to yourself. Switch to JBoss, Glassfish or TomEE.


Want a FREE WebSphere Eclipse IDE and development server with that?

UPDATE: We’ve posted some Java EE 6 development courses that use WebSphere and Eclipse to highlight this capability.  The best place to find these classes is in the WebSphere 8.0 Programming category.

UPDATE: If you are also interested in Spring tools for WebSphere development you might check out a related blog post – How about a FREE set of WebSphere and Spring Eclipse Development Tools?

UPDATE: Currently the versions of the Eclipse and WebSphere downloads are different than those detailed here.  The same process still works though and the important part is that if you want to run a WebSphere server from Eclipse (one of the main reasons to perform this setup) the Eclipse instance has to point to the IBM JVM. This is easiest to do by pointing it to the IBM JVM installed with the ‘WebSphere for Developers’ as outlined in this post.  Post questions if you have any as I try to keep up with the comments on this post.


For the longest time the biggest complaint we’ve heard from developers who use WebSphere is “We can’t just use Eclipse!”.  In fact, the fact that the only “official” development support IBM would provide for WebSphere was Rational Application Developer created an entire market for MyEclipse Blue of people that didn’t want to pay for RAD but developed for WebSphere.  Even MyEclipse Blue is not free though, it is just cheaper than RAD.

So to solve this problem you do not know how many WebSphere shops I’ve seen that:

  • Do development with Eclipse
  • Manually add Java EE/WebSphere JARs to the classpath
  • Try to automate the process of exporting an EAR and deploying to WebSphere the best they can

Well now it is MUCH EASIER!  IBM has just released FREE Eclipse plugins to deploy/start/stop WebSphere v7.0 and v8.0 servers from the Eclipse ‘Servers’ view.  I bet you aren’t used to hearing IBM and “free” in the same sentence!  These are only available for WebSphere Application Server v7.0 & v8.0 (no WebSphere 6.1, WebSphere Portal or Process Server) but these are some of the most common WebSphere environments right now and in the near future.

All of this is done with the “WebSphere Application Server Developer Tools for Eclipse” in the “WASdev” community on IBM Developerworks.  Although you might see a lot of discussion about the WAS 8.5 “Liberty” profile which is an early program of some other exciting things they are doing, the WAS Developer Tools for Eclipse is something you can use NOW.

Setup Steps

Although you can certainly get some more info on how to use these new tools from the official announcement and the WASdev downloads page, I figure I would take it one step further and give you a complete set of instructions along with some screenshots for doing this on Windows.  It is really easy to do.

First of all I am going to assume for now that you are only using this for WebSphere v7.0 or v8.0 and not the “early program” (or Alpha) WAS 8.5 Liberty edition.  The reason this is important is the version of Eclipse to use.  For WAS 7 & 8 you will use Eclipse Helios.

UPDATE: It has been pointed out that there are 32-bit and 64-bit versions of both Eclipse and WebSphere.  The type you use for both has to be the same.  I would suggest the 32-bit since for development you don’t really need the expanded memory addresses of the 64-bit.  If for some reason you are using different architectures for the two products and getting an error probably the easiest way to fix it is to get the Eclipse version that matches the WebSphere you have installed.

  • First you will need to have a Java installation just like any other Eclipse environment even though we will just use it for the updates.  Later we will link Eclipse to the JVM installed with your local WebSphere server (this will be important).  You can get the Java download here although make sure it is not a ‘Java SE 7’ download as the Eclipse we will start with wouldn’t support that.
  • Next, go get the Helios release of the Eclipse for Java EE Developers.
  • Unzip the Eclipse download into an empty directory where you want Eclipse software to run from.  Even after we update with WebSphere tools it will run from this directory.
  • Run the ‘eclipse.exe’ file in the root of where you extracted Eclipse and open Eclipse in an empty “workspace” directory.  We won’t be creating projects yet but we still need to open a workspace to run the updates we need.
  • Make sure you are able to connect to the internet from within Eclipse.  If you have a proxy configuration this might mean going into the Eclipse preferences (Window –> Preferences) and the ‘General –> Network Connections’ section to setup network details.  A lot of times though Eclipse might be able to pick up your native internet settings so I would try this only if you have problems in the next steps.
  • Close the preferences if you had them open.
  • Once Eclipse opens, select ‘Help –> Check for Updates’ and wait for the update sites to be contacted.
  • Leave the default selected to update ‘Eclipse IDE for Java EE Developers’ and click the Next button.


  • Click the Next button again to confirm the update.
  • Accept the license terms and click the Finish button.
  • Once the installation of updates is complete, click the Restart Now button.
  • When prompted, open to the same workspace as before.
  • From the running Eclipse, select Help –> Eclipse Marketplace.
  • On the dialog that appears, leave Eclipse Marketplace selected and click the Next button.
  • On the Search tab that appears, fill in ‘WebSphere’ into the box and click the Find button.


  • Select the WebSphere v7.0 or v8.0 tools depending on which you want and click the Install button next to the one you want.  Note that the WebSphere v7.0 tools have an 8.0.4 in the text description but this is just the version of the Eclipse plugins.  If you want to do both you can, just select one and continue and then repeat the process after restarting Eclipse after the first set of tools is installed.


  • Leave the option to install your chosen tool version and click the Next button.


  • Accept the license terms and click the Finish button.
  • If prompted about installing unsigned content click the OK button to continue the installation.
  • Once the installation of updates is complete, click the Restart Now button.
  • When prompted, open to the same workspace as before.
  • After Eclipse opens, exit from Eclipse.

So that’s all you need right?  Not quite.  Besides the Eclipse tools you will also need a local WebSphere 7 or 8 test server. I know some of you are saying “darn, I knew this couldn’t be completely free!” Fear not! I promised the development environment would be completely free and it is because IBM has offered for a while now the WebSphere Application Server for Developers product, a COMPLETELY FREE version of WAS for development that is NOT a trial or expiring edition and is built from the same codebase as the production versions. The best link I’ve found to go straight to the WAS for Developers downloads is here.  For those of you with IBM Passport Advantage download abilities there is also a ‘WebSphere Application Server for Developers – Eclipse Tools Edition’ which has all of this but there is also a lot of stuff you probably don’t need.

We will also need to link the Eclipse environment to the Java JVM installed with the WebSphere server.  If you don’t do this you won’t be able to define a WebSphere server in Eclipse as the WebSphere Developer Tools will check that you are using an IBM JVM.

So just a few more steps and we will be set!

  • After downloading WebSphere Application Server for Developers from the link above or here go ahead and install it.  This will differ slightly depending on the version so it isn’t detailed here but should be pretty straightforward.  I always suggest NOT installing under the Windows ‘Program Files’ directories as on Windows Vista and above I have seen cases where Windows won’t let you save WebSphere configuration files so your configuration changes are mysteriously “lost”.
  • Once you have WAS installed make sure you have a “profile” configured.  This is the configuration that will serve as your test server.  You can run the ‘Profile Management Tool’ if a profile isn’t created during installation.  If you run the Profile Management Tool I always like to select the “Advanced” profile creation because you can use the “development template” for better development performance, make sure the server uses the default ports and NOT have the server run as a Windows service.  No matter how it is created know the name of the profile that you will use.
  • After WAS for Developers is installed go to the directory where you unzipped Eclipse.  Find the ‘eclipse.ini’ file and open it with a text editor.  The extension may be hidden and just list the file type as ‘Configuration Settings’.


  • Once you have the file open, add the following lines to the start of the file, substituting for <WAS Install Root> the directory you installed WAS at.  In the screenshot below my <WAS Install Root> was ‘C:\IBM\WebSphere\AppServer’.  Save the file when it is like below.  Make sure when you save it the file extension is not changed.

<WAS Install Root>\java\jre\bin\javaw.exe


UPDATE: As suggested in the comments, another way to alter the JVM used to start Eclipse is to add the ‘-vm <Path to JVM>’ syntax to the ‘Target’ property of a desktop shortcut that is used to launch Eclipse.  Setting the value in the ‘eclipse.ini’ file is to set the default and the command line option overrides this.  Your approach will probably depend on if you develop WebSphere and non-WebSphere projects with the same Eclipse install.

  • Once you have modified and saved the ‘eclipse.ini’ file, open Eclipse again to the same workspace.
  • Close the ‘Welcome’ page if it appears and find the ‘Servers’ view along the bottom.  This should open by default in the ‘Java EE’ perspective that should also be the default.
  • Right click in an empty area and select ‘New –> Server


  • Expand IBM and select your version of WAS and click the Next button.  This is where you would have errors if you hadn’t started Eclipse with the IBM JVM.


  • Since this is the first WebSphere server you defined, hit the Browse button and find the root directory of the WebSphere installation.
  • Once you have the WebSphere installation directory click the Next button.
  • On the next page make sure the correct profile name is listed in the drop-down.  Also make sure to supply security settings if you enabled security when the profile was created.
  • Once your settings are configured click the Finish button.
  • Start deploying projects from your workspace by right clicking the WebSphere server and selecting ‘Add and Remove..’, start and stop the server, even open the WebSphere Admin Console by going into the ‘Administration’ menu when right clicking!  In short, do all the things you’ve ever wanted to do to deploy and test on WebSphere from Eclipse!



So now you have a way to do WebSphere development with completely free tools without having to deploy remotely, hack the project classpath, come up with Ant scripts just to export and deploy, etc.  Obviously this opens up a whole new realm of possibilities for WebSphere development.  You will have much more freedom to construct the development environment that suits your project best but still make sure you are testing against WebSphere.

Since this is obviously a thing we know our own clients have been looking to do for quite a long time we plan on using this in several areas.  We will likely release a few Java EE training classes that use Eclipse and WebSphere 7.0 just to prove this is a completely capable development environment and let people get familiar with it.  We will also start using this quite heavily in the Java EE 6 on WebSphere 8.0 courses that will be posted soon.  We will also use this in our Spring 3 classes since one of our unique offerings has always been offering Spring development training on WebSphere.  Look for another blog post soon about the best development environment to use for Spring development for WebSphere.

So start dancing in the streets, we can finally develop and test WebSphere applications on “regular” Eclipse!


What’s Happening With JBoss?

UPDATE (Aug 2012) – The officially supported JBoss EAP 6.0 is finally released.  People using the supported EAP version will have much less confusion and one of the goals of this article was to clear up confusion about what is happening with the open source and EAP versions and how they relate.

If you are going to be using the latest versions of JBoss training is really a requirement because there are LOTS of changes (for the better) and you might need to reinvent somewhat how you approach management of JBoss in various job roles.  Training will help get you there faster and spend less time trying to figure out the new platform.


One thing that I’ve found to be true for enterprise clients is people don’t always have time to keep up with what is going on in the cutting edge of technology because they are busy just trying to keep up with their own responsibilities.  Since we have a lot of clients that use JBoss I figure I would help bring everybody “up to speed” with what is happening with JBoss on the Java EE front.  There have been several developments recently and there will be more over the next several months.

The first thing to determine is what “edition” of JBoss you are talking about.  Ultimately this comes down to if you are paying RedHat/JBoss for a support subscription to access the “officially supported” version of JBoss.  This “officially supported” version of JBoss is the JBoss Enterprise Application Platform (JBoss EAP).  If you are not paying for a support subscription you are likely using the “free, open-source” version of JBoss Application Server (JBoss AS).

So what is the difference between the two?  Although these are both “JBoss” editions there are some important differences:

  • The JBoss EAP contains some version of JBoss AS.  You can find the relationship between the released versions here.
  • These editions are released at different times with JBoss EAP released sometime after the version of JBoss AS it contains.
  • The versions of these two JBoss “editions” do not often match.  They did match somewhat with JBoss 5.x but they do not match now.  More on this in a second.
  • The JBoss EAP is the only version that will often have bug fixes back-ported to older versions.  JBoss AS “may” have bug fix releases but it is often only applying bug fixes to the “next” version of JBoss AS.  If it is important to have bugs fixed in JBoss without moving to a new JBoss version or you compiling JBoss source code updates yourself the JBoss EAP is a great investment.
  • A JBoss EAP subscription includes access to the JBoss Operations Network which is a great product for managing and monitoring several JBoss servers.
  • The JBoss EAP includes and is verified against specific versions of other popular libraries like Hibernate and JBoss Seam.  Often fixes released to the JBoss EAP will include critical fixes for these included libraries also.  What versions of particular libraries are included is listed here.
  • The different versions of JBoss EAP and JBoss AS will be compliant and “certified” against different versions of Java Enterprise (Java EE).  This will be especially important for Java EE 6 as discussed next.

Current/Upcoming JBoss Versions

  • JBoss AS 5.1
  • JBoss EAP 5.1 – includes JBoss AS 5.1 internally
  • JBoss AS 6.0/6.1 – Not major internal changes although some changes in web service stack and JMS stack.  Good summary here. Will never be released as part of a supported JBoss EAP version.
  • JBoss AS 7.0 – Final/GA release available. Significant internal and administrative changes compared to JBoss AS 6.x.
  • JBoss AS 7.1 – Beta release available, not yet GA/Final. Significant internal and administrative changes compared to JBoss AS 6.x.
  • JBoss EAP 6.0 – not yet released (early 2012?). Will include JBoss AS 7.1 internally

JBoss AS Downloads

JBoss EAP Information

Java EE 6 Certification

The other thing that causes some issues right now is what it means to be “Java EE Certified” for Java EE 6.  Java EE 6 introduced the concept of “profiles” so that Java EE servers could be certified against a subset of the Java EE specifications but not against the “full profile” of all specifications.  This is important because some Java EE technologies like EJB 2.x Entity EJBs are on their way out anyway now that we have modern replacements like Java Persistence (JPA).  The only profile that Java EE 6 defined besides the “full profile” is the “Java EE 6 Web Profile”.

The following are some of the highlights of the Java EE 6 Web Profile (not a complete list but the major things):

  • Servlet 3.0
  • JSP 2.2
  • JSF 2.0
  • JPA 2.0
  • Contexts and Dependency Injection for the Java EE Platform 1.0 (CDI)
  • EJB 3.1 “Lite” (This includes basically only non-remote Session EJBs)

There are some significant technologies that are in the “full profile” but NOT required in the “Web Profile” (not a complete list but the major differences):

  • JMS
  • Web Services (JAX-WS, JAX-RS “RESTful”, and JAX-RPC)
  • All of EJB 3.1 (including 2.x Entity EJBs, Message Driven EJBs, EJB Timer)
  • JavaMail

So servers that are certified against the “Java EE 6 Web Profile” are only “required” to have a subset of Java EE 6 technologies.  Now most of the JBoss AS versions offer technologies above and beyond the Web Profile but JBoss AS 7.1 (which will be included in JBoss EAP 6.0) is the only version that will target certifying against the “Full” Java EE 6 profile.  There is a good discussion here about exactly what it means (for JBoss AS 6.x anyway) to have been tested against the Java EE 6 web profile but also offer additional technologies.  It is also interesting to note that in the downloads of JBoss AS there is a download for JBoss AS 7.0.x which is “Web Profile Only” and has been officially certified for Java EE 6 by Oracle and there is an “Everything” download which has additional technologies but is specifically advertised as not being officially certified.

JBoss Versions and Java EE Certification

  • JBoss AS 5.1 – Java EE 5 Certified
  • JBoss EAP 5.1 – Java EE 5 Certified
  • JBoss AS 6.0/6.1 – Not officially certified for Java EE 6 Web Profile but tested internally by JBoss against the web profile test suite
  • JBoss AS 7.0.x – Officially certified for Java EE 6 Web Profile. An “Everything” download available with more
  • JBoss AS 7.1.x – Will be certified against “Full Java EE 6 profile”. Good description of the strategy here.
  • JBoss EAP 6.0 – Will be certified against “Full Java EE 6 profile”. Good description of the strategy here.

JBoss Versions and Support/Bug Fixes

Finally, I think the other consideration that will be important to people when switching will be consideration of how they will deal with the inevitable problems/questions that come up and how confident they might be about the software being fixed with bugs.  For those that this issue is mission critical, I would again highly suggest looking into a subscription to the JBoss Enterprise Application Platform.  This is the only form of JBoss that will have a support service level agreement and where bugs will be backported to previous versions for several years according to the JBoss Enterprise Middleware support policy.

When using one of the JBoss AS releases the only “support” that is available is from the JBoss Community and any available JBoss AS Documentation.  For users of JBoss AS I think it is important to consider the level of support from the JBoss community since that support comes primarily from three sources:

  • Other JBoss users that may have similar issues/questions
  • JBoss AS developers working on the open source project
  • JBoss EAP staff working on support of JBoss EAP specifically

Of course this community support would also apply to clients of the JBoss EAP since it is based on a version of JBoss AS and would be useful above and beyond the normal “official” support available for JBoss EAP.

The other thing to consider is if there have been bug fix releases of the JBoss AS versions or not.

Thoughts on Level of Community Support/Bug Fix Releases for JBoss AS Versions

  • JBoss AS 5.1 – No bug fix releases.  Still lots of users using this version, JBoss AS developers not as active, JBoss EAP staff active as it is part of a supported JBoss EAP version.
  • JBoss AS 6.x – 6.1 is a bug fix release of 6.0 but is the only one.  Lots of users on this one based on downloads, JBoss AS developers and JBoss EAP staff not as active since this version is very different than JBoss AS 7.x and JBoss AS 6.x will never be part of a supported JBoss EAP release.
  • JBoss AS 7.x – This has already had two 7.0.x bug fix releases in only two months which is better than previous JBoss AS versions.  Lots of community activity from users and JBoss AS developers.  JBoss EAP staff also likely active getting ready to include JBoss AS 7.1 in JBoss EAP 6.0.


So where does this leave you as a JBoss user?  What version should you be using now or planning to move to?  Every situation is different based on different factors like:

  • Are you migrating existing applications or developing new applications?
  • Do you use technologies that are not required by the Java EE 6 Web Profile?
  • Do you have applications that depend only on the Java EE specifications or do they utilize internal JBoss infrastructure (like custom “JBoss SAR” or “Service Archives”)?
  • How much do you need to configure administratively outside of your deployed applications (EAR, WAR, etc) and how hard would it be to determine how to configure those in a new version?
  • How important is “Full Java EE 6” certification compared to “Java EE 6 Web Profile” certification for you?
  • How important is the support offered by JBoss EAP?
  • Is there some kind of deadline you are working under that might prevent you from waiting for JBoss AS 7.1 or JBoss EAP 6 and the certification of the full Java EE 6 profile that would bring?

Certainly without knowledge of your particular situation it would be unwise for me to offer any kind of direct suggestion here.  In general though I might be hesitant to use JBoss AS 6, at least for very long, as this is not getting the attention of as many from the JBoss AS developer or JBoss EAP support staff groups and JBoss has decided that they will not release it as part of any supported platform.  There is also some question about using anything like JBoss AS 6.0 or JBoss AS 7.0 which is not certified against the full profile but offers varying degrees of additional features between the two Java EE 6 profiles.

For those that might value stability and Java EE certification above all else, and who do not have to start using new Java EE 6 features on some tight deadline, I might hold out for JBoss AS 7.1 or JBoss EAP 6.0.  You could even start investigating that migration now with the release of JBoss AS 7.1.0.Beta1!

, ,


Who Was First to Java EE 6?

I was doing some research on JBoss the other day and found an interesting press release from JBoss.  They claim they were the first to release “Java EE 6 via Platform-as-a-Service” with “OpenShift”.  While this is certainly true the announcement could cause some confusion about JBoss “support” and “certification” of Java EE 6.

Although I won’t get into the cloud aspects of this product I thought it was interesting to actually dive into the details of the Java EE 6 side.  I guess it really depends on how you define “first to release Java EE 6”.

For those of you that are JBoss clients you might be thinking “Great!  JBoss now has support for Java EE 6”, and you’d be wrong!  The only thing “JBoss” that is certified for Java EE 6 is the recently released OPEN SOURCE and UNSUPPORTED JBoss Application Server 7.   They do not have a version of the JBoss Enterprise Application Platform (JBoss EAP), which is the product you actually pay to receive support for, that is certified for Java EE 6.

It also depends on how you define “certified”.  As you can see on the Oracle Java EE certification page, JBoss Application Server 7 is only certified for the “Web Profile”.  This is a new concept in Java EE 6 that allows servers to be certified for a subset of the Java EE technologies (mostly the newest stuff) but not certified against all of the technologies.  In particular the “Web profile” doesn’t require JMS, web services, MDBs and a few other technologies.  JBoss Application Server 7 supposedly supports some of these even though they don’t “have to” but they are not certified for the “Full profile” which would verify the compatibility tests of all Java EE technologies.  You can find an interesting discussion some of us in the JBoss community had with those in JBoss about this approach here.

Now the good thing is that JBoss does plan to release support for the “Full profile” Java EE 6 with the release of the JBoss Enterprise Application Platform 6 (the version numbers between EAP and open source server are going to be out of sync).  This isn’t expected until early 2012 though.   Luckily those of us in the JBoss community were able to convince those driving JBoss development that there was value in the full Java EE 6 profile and not to release the JBoss EAP until that full profile support was provided.  We all felt it would be more confusing to have a version of the EAP providing only Web profile certification and then later to have full profile certification.  After all, having different versions between the open source JBoss Application Server 7 and the JBoss Enterprise Application Platform is going to be bad enough.

So if you look at the Oracle Java EE certification page, there is a popular production supported server that provides support for the full profile of Java EE 6.  That server is WebSphere Application Server 8.0.  That’s right, WebSphere BEAT JBoss (again)!  Certainly WebSphere was not the very first application server to support Java EE 6, that distinction goes to Glassfish 3.0 released as the Java EE 6 “reference implementation”.  But if you look at the “Big 3” Java application servers of WebSphere, WebLogic, and JBoss, WebSphere was first.

So about the only way you could claim that “JBoss was the first to release Java EE 6” is if:

  • You accept an unsupported, open source product (which most clients don’t want to use in production anymore)
  • You accept a “Web profile”-only version and don’t need ALL of Java EE 6
  • You use some other qualifier like “via Platform-as-a-Service”

So anyway, back to the press release.  Why would JBoss want to offer something like this if there are so many ways to pick it apart?  I think the date of the press release is telling.  The press release is from August.  WebSphere Application Server 8.0 was released in June.  I think JBoss knew they were running out of time to put their “We were first” argument out there.

Also, a closer reading of the press release does make it clear that OpenShift is targeting developers right now so the issue of production support is not meant to be provided with this current release.  The first sentence of the second paragraph of the release, “OpenShift is a free PaaS for developers who leverage open source” certainly puts this offering in the correct context.

Ah the spin of product press releases…

EDIT:  I’ve made some minor changes to be more clear that this post is not meant as a hack job on JBoss “OpenShift” but as a comment on the press release concerning OpenShift which could be read in confusing ways.  In particular phrases like “supports Java Enterprise Edition 6” can be read in confusing ways that would imply things that are not currently true about JBoss Application Server.  For those of our clients that might not follow developments in JBoss quite as closely as I do hopefully this information is useful.

, ,


Running a Local SMTP Server

When developing applications that send out e-mails, it helps to run a local e-mail server. Java Email Server is a simple SMTP server perfect for unit testing.


Download and extract the ZIP file somewhere, say C:\Program Files\JES.

Open the file bin/ntservice.bat using Notepad. Set the JES_HOME_DIR variable to the root of the install folder.

set JES_HOME_DIR=c:\Progra~1\JES

Set JDK_HOME_DIR to the root of Java. Note: You must point to a JDK directory and not a JRE.

set JDK_HOME_DIR=C:\Progra~1\IBM\SDP\runtimes\base_v7\java

If you are using IBM JDK, set the JDK_MODE to classic.

set JDK_MODE=classic

Save changes.

From the bin directory of JES, run this command to install the service:

ntservice.bat -install


Open Services control panel applet. Start JavaMailServer service to start the SMTP server.


Open mail.conf from the root folder. Set the local domain name:

Any e-mail sent to the local domain will be saved by this e-mail server (and will not be forwarded to the actual SMTP server of the domain). For example, if we set this to then e-mails sent to any address with domain will be considered local to this server and it will be saved right there. This is great because, you don’t want to send test e-mails to actual users. That will only confuse the recipients.

Set the default user’s e-mail:

This comes very handy during development. You can send e-mails to any user with domain. All e-mails will be deposited to the default user’s box. This way, you can configure only one POP3 account in your mail program for the default user and pull out all e-mails using that.

Save and close mail.conf.

Open users.conf. Here, add the default user. The format is user.<username@domain>=<plain text password>. So, to add a user called "admin" with password "pass", do:

Save changes.

Restart the service.

Note: E-mails sent to non-local domain will be relayed by JES. Many ISPs block SMTP protocol to prevent spamming. For example, I can’t send e-mail to Gmail’s SMTP server without using my ISP’s SMTP server. Relaying might be hard to achieve. But, mails to local domain is guaranteed to work.

Configure Mail Reader

In your mail reader, configure POP3 as follows:

Hostname: localhost.
User ID: You must enter the full domain name.
Password: pass

For SMTP server, enter localhost as the hostname.

Now, you will be to send e-mail to any user of the local domain. You can pick up all of those e-mails from the single POP3 user account.

No Comments

Struts 2 Project Template for RAD 7.5

Rational Application Developer (RAD) 7.5 supports only up to Struts 1.3. I do not anticipate IBM to support Struts 2.0 any time soon.

Adding Struts 2.0 to a web project is not rocket science but it can take up a bit of time. You need to assemble the right JAR files and create struts.xml in the right place and what not. I have created a template project file that will avoid a lot of headache and you can be up and running with Struts 2.0 in no time.


Features of the Template Project

The dynamic web project is for Servlet 2.5 (or Java EE 5) spec. By default, Struts2 distribution uses Servlet 2.4 spec. I changed the web.xml to use the new version.

The project uses WebSphere Application Server 7.0 as the target runtime.

Using the Template Project

You should be able to create a new dynamic web project from the template very easily. Just follow these steps.

1. Launch RAD 7.5.

2. From the menubar, select File > Import. Expand Other and select Project Interchange.

3. Click Next.

4. Import the Struts2Template from the downloaded ZIP file.

5. You need to rename the project to something more suitable. Right click the project and select Refactor > Rename. Enter a different name and click OK.

RAD does not allow you to deploy a web project directly to a test server. You need to create an enterprise application project and add the Struts2 web project to it. Follow these steps.

6. From the menubar, select File > New > Enterprise Application Project.

7. Enter a project name. Click Next.

8. Select the Struts2 web project.

9. Click Finish.

That’s it. You should do a quick test to make sure that things are in order.

Validating the Project

1. Start the server if it is not running.

2. Add the enterprise application project to the server.

3. There is an index.html file in the Struts2 project. Right click it and select Run As > Run on Server.

4. Click the Hello World link. You should see the Hello World page.

Understanding the Project Structure

The WebContent/WEB-INF/lib folder contains a minimal set of JAR files needed by Struts2.

Under Java Resources/src folder, you will see the struts.xml file.  After the project is built, RAD copies all .class files and any other files from the source folder to WEB-INF/classes. You should never directly edit files in the classes folder.

A sample action class is provided as com.webage.struts.HelloWorld. The action is registered in struts.xml.


JBoss Java EE 6 Certification Survey

A few months ago JBoss Application Server v6.0, the open-source unsupported version, was released.  At the time in the announcement it was mentioned that the 6.0 version had been certified for the Java EE 6 ‘Web Profile’, which requires a subset of the Java EE technologies, but that the 6.0 version had not been certified against the ‘full’ Java EE 6 profile.  The reasoning given was that ‘resource constraints’ would add to the time taken to perform the full certification and JBoss felt it was important to release JBoss AS 6.0 to the community so that people who wanted to begin developing Java EE 6 applications with JBoss could do so.

It wasn’t very long before there were discussions in the community trying to clarify what this meant.  One thread in particular became very popular and has since received almost 14,000 views showing that this is clearly an important topic for JBoss users.  One of the main questions was the level of support for the technologies that JBoss has supported in the past but are not required of the Web Profile.  JBoss developers clarified that JBoss did support technologies like JMS, JAX-WS web services, and others but that they were just not “certified” because the certification had not been done for the full Java EE 6 Profile.  Of course this raised simply more questions and it was quickly clear that most of the community was unclear about the direction of JBoss, especially for the future JBoss Enterprise Application Platform (JBoss EAP) which is the supported version many clients use.

To help get the opinion of the community in a little more scientific way than just forum posts I created a survey about some of the questions and issues surrounding JBoss Java EE 6 certification.  The survey is still open so you can take it if you haven’t already but I wanted to summarize the results so they could help drive the progression of JBoss before JBoss AS 7.0, which is the open source version that will be used in JBoss EAP 6 (yeah, I know it’s confusing), is finalized.  Obviously commenting after the fact wouldn’t help anyone so this survey was a way for the community to speak up now.

Survey Summary

First of all the survey seemed to be a hit and had 269 responses when I did the analysis described here.  The thread that introduced the survey has even been listed as a “featured discussion” in the JBoss forums so maybe that is something done by some of the JBoss developers to help improve community feedback (which I appreciate) and show they are interested in the opinions of the JBoss community.

Before getting into further analysis below I think I can summarize some of the biggest things that seem to be apparent from the results.  These points are for the full set of responses, I’ll break down some other groups later.

  • By an almost 3-1 margin people were surprised that JBoss AS 6.0 doesn’t support the full Java EE 6 profile
  • Generally people are willing to wait several months if that is what it takes to certify JBoss AS for the full Java EE 6 profile
  • More people are willing to wait however long it takes for full certification compared to the number not willing to wait at all
  • By a 3-1 margin people feel both JBoss AS open source version and JBoss EAP should be certified for the full Java EE 6 profile
  • About 40% of people would be “very likely” or “would definitely” switch to another server if JBoss AS or JBoss EAP were not certified for the full Java EE 6 profile
  • There was a good sample of JBoss EAP clients with 1 out of 4 indicating they were an EAP customer

First of all, for full accountability I’ve made the summary results of the whole survey available here along with a spread sheet of all of the individual responses available here (for those statistics geeks out there).  Other files are also linked at the bottom of this post.

Detailed Analysis

So let’s look at each of the questions and see what we might deduce.

Question #1 asked about various features and how important they were.  The clear winner here is obviously performance which I think makes sense since most people have been probably using some form of JBoss AS 5.1 (even within EAP) which has the highest startup time of any recent JBoss version.  So clearly the JBoss AS 7.0/JBoss EAP 6.0 focus on performance is critical.  For the two certification options it is interesting that people generally took their position on Web Profile certification and either felt that full profile certification was either more important or less important as the full profile option had more responses on the extreme.  The average for full profile certification was higher than web profile certification though so more people felt that full certification was more important.  Ease of administration did edge out both certification options although this has long been a weakness of JBoss compared to other competitive application servers so again no surprise there and a good support for the effort on usability of JBoss currently underway.


I think question #2 about if people were surprised that JBoss AS 6.0 doesn’t support the full Java EE 6 profile is pretty clear cut.  I think this makes it important for those guiding the JBoss development to clearly communicate the intentions for the upcoming versions of JBoss AS and JBoss EAP to address this gap in communication.

Arguably the question could be called misleading since you can make the argument that “doesn’t support” is different than “fully certified” but I think the result is clear that without the “fully certified” stamp of approval there will always be doubt that will be hard to justify to managers, etc.


Question #3 on how long people would be willing to wait clearly indicates that the community would likely be willing to wait some time, as long as it didn’t drag on like JBoss AS 5.0 seemed to.  Hopefully the difference between being able to release a Web Profile certified version and a version certified for the full Java EE 6 profile would fall in this range.  For those not willing to wait, people can start using JBoss AS 6.0 right now for the newest cutting edge technologies, as suggested by JBoss developers.


Question #4 is pretty clear that people want both the open source and supported platform to be certified for the full Java EE 6 profile.  Part of this could be people wanting to use the JBoss AS server without being an EAP client or for EAP clients to have more confidence that full Java EE 6 profile certification was not something introduced at the last minute.  Both are valid reasons though so hopefully this is what we might see (otherwise there would be a pretty big distinction between JBoss AS and JBoss EAP).


Question #5 on how likely people are to switch is much more interesting when you break down by groups which I’ll do later.  Overall though the notion that JBoss might not be certified for the full Java EE 6 profile has got some people thinking about if they will stick around.  Certainly with many more open source Java EE options out there compared to 5 years ago having 17% of your users say “I’m outta here” should cause some concern.


I asked question #6 to really get an idea of how many people taking the survey were JBoss EAP clients (and therefore paying JBoss money 😉 ) because a survey only advertised on the forums could attract a very different subset of people.  I think there is a good sample even if you assume all those that said “don’t know” are not EAP clients. This also lets us break down the results to focus on JBoss EAP clients only.


Group Breakdown

I won’t do much more than highlight the major findings for some groups and link to the file that has the complete cross-tabulated results but I think there are some interesting findings for some groups.  I’ve also indicated how many responses are in each group compared to the 269 total responses.

EAP Customers (66) – I think the group JBoss may be most interested in is how the people who indicated they are a JBoss EAP client responded.  I think the interesting points are:

  • More likely to switch servers if full profile certification is not done (49% “very likely” or “would definitely switch” compared to 40% of all surveys)
  • More willing to let JBoss EAP be the only thing certified for full profile (since they are paying for EAP anyway and not using JBoss AS)
  • There was not really significant difference in the rating averages of the 4 features in question #1
  • There was a difference in the distribution of responses to question #1 though with actually FEWER responses of ‘Extremely Important’ for the certification options and more ‘Very Important’ so kind of bunching up around ‘Very Important’ instead of being quite so widely distributed as all responses were
  • Just a few percent higher on being surprised about question #2 on the lack of full profile in JBoss AS 6.0
  • More bunching up around waiting 0-3 or 3-6 months for full profile certification

EAP Customers “very likely” or “would definitely” switch servers (32) – You might look at the points above and think “EAP clients won’t really have a different opinion than the larger community”.  But if you look further at the subset of EAP clients who are more likely to switch servers there are some clear signs of why they would switch

  • This group feels MUCH more strongly that full profile Java EE 6 certification is ‘Extremely Important’, even more important than performance and ease of administration
  • This group is MUCH more surprised that JBoss AS 6.0 is not certified for the full Java EE 6 profile, by a factor of 9-1 compared to 3-1 from all surveys
  • MUCH more bunched up around waiting 0-3 or 3-6 months for full profile certification although this comes from losing responses on both extremes

All respondents who felt full certification was “very” or “extremely” important (172)

  • Similar 8-1 ratio of surprise as the previous group that JBoss AS 6.0 is not full profile certified
  • MUCH more interested in seeing both JBoss AS and JBoss EAP certified for the full profile
  • More likely to switch servers with the “not likely” category dropping 15% and almost all of these showing up in “very likely” or “would definitely” switch categroies
  • Fewer people not willing to wait for certification and these people shift to the 0-3 and 3-6 month range with little change at the longer wait options

All respondents who felt full certification was “not at all” or “somewhat” important (57)

  • This group is not really surprised to hear JBoss AS 6.0 is not full profile certified
  • This group places the biggest distinction between full profile and web profile certification as the difference in how “important” each are is 1.5 points out of 5 different
  • Surprisingly there are a higher percentage in this group willing to wait “however long it takes” for full profile certification although there are also more people on the “not willing to wait” and 0-3 month range so more extremes on that question
  • This group is more willing to accept having only JBoss EAP full profile certified
  • Not surprisingly this group isn’t going to switch servers if JBoss does not certify against the full Java EE 6 profile


Clearly this survey confirms that full Java EE 6 certification is an issue that the JBoss community cares about.  Hopefully the surprise at the approach for JBoss AS 6.0 and the value the community (especially EAP clients) place in full Java EE 6 certification will convince those involved in some of these decisions at JBoss to more clearly communicate the plans for yet-to-be-released versions of JBoss AS and JBoss EAP.  Personally I think they are and hopefully this survey has helped that process.


Many thanks,

Stuart Smith

Java and Administration Lead

Web Age Solutions


PS. If you are still reading JBoss is obviously important to you so you might be interested in some of the popular JBoss training courses my company offers… (sorry, had to plug the company on the company blog)

– JBoss 5.x (AS and EAP) Administration and Clustering on Linux or Windows

Java EE 5 Programming with JSF, EJB 3.0, and JPA on JBoss 5.x

Java Enterprise Programming with JBoss Seam 2.x

All Survey Files

Spreadsheet with all responses collected

Summary with all responses included

Summary of respondents who are EAP clients

Summary of EAP clients “very likely” or “would definitely” switch servers

Summary of all respondents who felt full certification was “very” or “extremely” important

Summary of all respondents who felt full certification was “not at all” or “somewhat” important

Summary of all respondents “not likely” or “somewhat likely” to switch servers

Summary of all respondents “very likely” or “would definitely” switch servers