Java EE Articles

WebSphere 9 Coming Soon?

Posted by Stuart Smith in Java EE, WebSphere on April 10, 2013

I know for those of you out there using WebSphere, the initial reaction to the title of this blog post is probably “But we haven’t even finished migrating to WebSphere 8.0/8.5!” I myself didn’t think a new WebSphere version could be waiting in the wings but there have been a few interesting data points to consider:

- Java EE 7 should be final by end of May this year (http://java.net/projects/javaee-spec/pages/Home).

- Many Java EE 7 JSRs are already in final review (http://jcp.org/en/jsr/stage?listBy=proposed).

- IBM Developerworks has betas of 9.0 versions of development tools (https://www.ibm.com/developerworks/mydeveloperworks/blogs/wasdev/entry/download?lang=en)

- IBM Redbooks had a residency open to update several core WebSphere Redbooks to “the latest release of WebSphere Application Server”. This was only open to IBM employees since people who work on the Redbook would obviously get a “sneak peek” at the next WebSphere.

Although thinking about when WebSphere 9 might be released is interesting, I think there is another possibility, that there will be some “intermediate” release that includes updates mainly to the Liberty profile, the lightweight server that IBM is trying to tailor to developers. Perhaps there will be something like an 8.5.5 release mainly to pick up updates to the Liberty profile.

Read the rest of this entry »

No Comments

The Performance Evil that is JSF dataTable

Posted by Bibhas Bhattacharya in Java EE on August 15, 2012

In JSF 1.x, dataTable was bizarrely inadequate and unnecessarily complicated. Things have become much easier in JSF 2.0 and it’s a pleasure to work with. But, don’t let that lull you into a false sense of security. There are major performance issues larking behind.

Let’s say that you have a managed bean that returns a list of products from the database by using the ProductDAO class.

@ManagedBean
public class Controller {
    private Product item = new Product();

    public List<Product> getProducts() {
        return ProductDAO.getProducts();
    }

    public String edit(Product toEdit) {
        this.item = toEdit;

        return "edit_product";
    }

    //getItem/setItem...
}

Now, we can build a view that shows the product list.

<h:dataTable id="products" value="#{controller.products}" var="current">
    <h:column>
        <f:facet name="header">Product Name</f:facet>
         #{current.name}
        <h:commandButton value="Edit" action="#{controller.edit(current)}" />
    </h:column>
</h:dataTable>

When the view is rendered, it will look something like this.

Now, let’s reveal the performance horror that the dataTable is. During the rendering phase, getProducts() is called repeatedly, once for each item in the list. That means, you are loading the entire list repeatedly from the database. This seems prodigiously wasteful. I don’t see why JSF couldn’t get the list once and simply iterate through it to render the table.

Next, when you click the Edit button, things get even worse. The getProducts() method is called 2xN number of times where N is the number of items in the list. To render the edit form, all you really need from the database is the item that is being edited. Under this circumstances, dataTable is doing a terrible job.

OK, so, what can we do about this. First, you need to cache the list in a member variable and access the database only if we haven’t already done so.

@ManagedBean
public class Controller {
    private Product item = new Product();
    private List<Product> productList = null;

    public List<Product> getProducts() {
        if (productList == null) {
            productList = ProductDAO.getProducts();
        }
        return productList;
    }

    public String edit(Product toEdit) {
        this.item = toEdit;

        return "edit_product";
    }

    //getItem/setItem...
}

This will cure most of the ills. But, there is still the issue of unnecessarily loading the entire list just to render the edit form. The solution for that is to use a GET request. Get rid of the edit() method and instead add the loadProduct() method that will load the product being edited.

@ManagedBean
public class Controller {
    private Product item = new Product();
    private List<Product> productList = null;

    public List<Product> getProducts() {
        if (productList == null) {
            productList = ProductDAO.getProducts();
        }
        return productList;
    }

    public void loadProduct() {
        int productId = item.getId();
        item = ProductDAO.getProductById(productId);
    }

    //getItem/setItem...
}

In the edit form page, say, edit_product.xhtml, setup GET request by adding this metadata.

<f:metadata>
    <f:viewParam name="productId" value="#{controller.item.id}"/>
    <f:event listener="#{controller.loadProduct}" type="preRenderView"/>
</f:metadata>

Finally, change the dataTable to use <h:link> instead of a <h:commandButton>.

<h:dataTable id="products" value="#{controller.products}" var="current">
	<h:column>
		<f:facet name="header">Name</f:facet>
		#{current.name}
		<h:link outcome="edit_product" value="Edit">
			<f:param name="productId" value="#{current.id}"/>
		</h:link>
	</h:column>
</h:dataTable>

That should do it. If you are still hatin’ dataTable, then go with <ui:repeat>.

No Comments

First Java EE 6 Web Service Class Released

Posted by Stuart Smith in Java EE, New/Updated Courses, SOA & Web Service, WebSphere on July 25, 2012

We have just released our first web service class as part of our Java EE 6 courses:

WA2087 Programming Java SOAP and REST Web Services – WebSphere 8.0 / RAD 8.0

Java EE 6 contains two ways to write web services, JAX-WS for “classic” SOAP web services and JAX-RS for REST web services. This class covers how to implement both styles. The course also covers securing both types of services and compares the two styles so you can decide which might be appropriate for different situations.

I think this course will be especially useful for people that support JAX-RPC web services from J2EE 1.4 but need to look to what are the more recent Java standards for web services. Java EE 6 put JAX-RPC on the “proposed optional” list of technologies which means in the future Java EE servers may not be required to support JAX-RPC. Although I expect WebSphere will still support it now is a good time to start looking for how to migrate JAX-RPC web services to more recent standards like JAX-WS and JAX-RS.

This course is part of our WebSphere Application Server 8.0 Programming course map. We have other courses that cover just JAX-RS or just JAX-WS as well as a course that covers REST services with JAX-RS and the AJAX clients that are most common for REST services.

If you have any questions about these courses feel free to contact us.

No Comments

Eclipse Juno is Here!

Posted by Stuart Smith in Eclipse, Java, Java EE on June 28, 2012

What does the end of June and Java development have in common? Looking forward to the yearly coordinated release of all the latest Eclipse updates. This year the release is code named “Juno”. The release in June 2011 was “Indigo”.

This year marks the 7th time that the “Simultaneous Release” approach has been used that lets a new version of the underlying platform and all of the projects that build on top of it release. This has helped to greatly improve the compatibility between projects and the stability of the Eclipse platform as a whole. It also helps the numerous commercial products that are based on Eclipse count on a consistent schedule and release updates quickly based on the new updates. This year there were about 70 Eclipse projects part of the Juno release which expands on the 62 that were part of Indigo last year.

If you want to get started the first place to go is probably the usual Eclipse downloads page. This has been updated for links to the Juno versions of several different “pre-configured” combinations of Eclipse tools besides just the “basics” of the core platform. One of the most popular downloads is the “Eclipse for Java EE Developers”.

Now I will be the first to admit that like most of you, I can’t spend too much time looking at the new features that are coming out before they are released. So this post is more of a “news” post and future posts will dive into some of the details about what is new. Probably one of the best places to start for this kind of info are some of the “New and Noteworthy” pages like the one for the Java EE tools and the one for the core platform itself and the Java tools.

Probably one of the biggest changes is that the “default” version for the Eclipse SDK, which is the core of the platform is Eclipse 4.2. The Eclipse 4.x platform has been in the works for over a year but this is the first release where it is the “default”. All of the previous simultaneous releases were using the Eclipse 3.x platform so this has definitely been a measured process that Eclipse has gone through. It appears the “regular” Eclipse user won’t notice this much though compared to Indigo except for an updated UI style. For anyone developing Eclipse plug-ins or perhaps RCP (Rich Client Platform) applications using Eclipse there are more changes, although it is said that Eclipse plug-ins developed for previous Eclipse versions will have “binary compatibility” with the new version so hopefully this would be a smooth process. Certainly anyone in these categories will want to check out the Eclipse 4.x SDK page for more details.

BTW, if you want to set your calendars now, the next major release will be June 26th, 2013. This will be codenamed “Kepler” in keeping with the astronomical theme which has also recently started picking names that are alphabetical.

No Comments

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

Posted by Stuart Smith in Java EE, New/Updated Courses, WebSphere on June 12, 2012

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

Posted by Bibhas Bhattacharya in Java EE on June 6, 2012

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.

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.
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"/>
</h:form>

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.

<h:head>
<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">
$(function(){
    $("#form\\:dateOfExpense").datepicker();
});
</script>
</h:head>

2 Comments

Understanding JSF View Parameters

Posted by Bibhas Bhattacharya in Java EE on May 17, 2012

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) {
		this.id = id;
		this.name = name;
	}

	public Customer() {
	}
	public String getId() {
		return id;
	}
	public void setId(String id) {
		this.id = id;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.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.

@ManagedBean
@RequestScoped
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="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core"
	xmlns:h="http://java.sun.com/jsf/html">
<h:head>
	<title>Home</title>
</h:head>
<h:body>
	<h:form>
	Search customer by id:<br />
		<h:inputText value="#{mainController.lookupId}"/><br />
		<h:commandButton type="submit" value="Submit"
			action="#{mainController.doLookup}" />
	</h:form>
</h:body>
</html>

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="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core"
	xmlns:h="http://java.sun.com/jsf/html">
<h:head>
	<title>Result</title>
</h:head>
<h:body>

	<p>
		<b>Name:</b> ${mainController.customer.name}
	</p>
</h:body>
</html>

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:

Map URL parameters in a GET request to managed bean properties.
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:

<h:head>
	<title>Result</title>
</h:head>

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

<h:body>
	<p>
		<b>Name:</b> ${mainController.customer.name}
	</p>
</h:body>

There are many things going on here:

<f:viewParam> must appear within <f:metadata>.
<f:metadata> must appear directly under the view root. That is, you can not define it within <h:head> or <h:body>.
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.
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" />
</h:form>

No Comments

Goodbye Tomcat!

Posted by Bibhas Bhattacharya in Java EE on May 17, 2012

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.

22 Comments

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

Posted by Stuart Smith in Eclipse, Java EE, WebSphere on December 20, 2011

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.

ORIGINAL 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.

-vm
<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!

Conclusion

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!

34 Comments

What’s Happening With JBoss?

Posted by Stuart Smith in Java EE, JBoss on December 2, 2011

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.

Conclusions

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!

Java EE 6, JBoss 6, JBoss 7

4 Comments