WebSphere 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

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!


New WebSphere 7.0 “Administration Fundamentals” Course Released

We have found that often there are groups of people at WebSphere clients that need some level of knowledge with WebSphere administration beyond the “Overview” type of class but not to the same level of knowledge needed by those managing WebSphere systems day-to-day.  This is particularly true with application developers, testing staff, and other support roles that are not full WebSphere System Administrators.

To help better support the knowledge level these types of people need we have released a new 3 day course, WA1976 WebSphere Application Server 7.0 Administration Fundamentals.  This course covers topics like application deployment, management of database and messaging resources, troubleshooting, security, and web services.  Also, although it does not cover the configuration of a WebSphere cluster in depth it does introduce the architecture and terminology that is involved in a WebSphere cluster.

Certainly this course is not appropriate for every audience.  In particular, those that are managing a production WebSphere clustered environment would be better suited to our “full” 5 day WebSphere administration classes, WA1700 for Windows and WA1840 for Linux.  But by offering several different courses on WebSphere 7.0 Administration we feel clients will be able to better select the course that is appropriate for their audience.

No Comments

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.

, ,


Advanced WebSphere 7.0 Administration Course Descriptions Posted

During the first part of this year we have seen a number of WebSphere clients moving to the 7.0 version with their WebSphere environments.  Since many clients have WebSphere administrators that are skilled enough where they don’t need the “basic” administration course we are often asked about more advanced training for this group.  In support of this we have just posted several new course descriptions, described below, for various advanced WebSphere 7.0 administration courses.  These courses are also good for those that are new to WebSphere but need more training in particular areas after attending our primary WebSphere 7.0 administration course.

Since the WebSphere administrators who would take an advanced class are also often not able to attend a 4-5 day training class we have kept the advanced courses short and focused.  You can have the flexibility to let your senior WebSphere administrators attend a class and develop their skills without being unavailable in training for a full week or perhaps even save travel dollars by running 2 classes the same week.  For more information about pricing and availability of these courses contact your Web Age Solutions sales representative.

You can also find these courses linked in our latest version of our WebSphere Application Server 7.0 Administration Course Map

WA1953 Administrative Scripting with WebSphere Application Server 7.0

This 3 day course covers in depth how to perform many common WebSphere tasks using the WebSphere scripting libraries.  Rather than using the Administration Console, which is prone to human error, students will learn how to create automated and repeatable procedures modify WebSphere environments with scripting.  Students learn the Jython language in addition to the commands available in a WebSphere environment.

WA1941 WebSphere Application Server 7.0 Performance Tuning

Often a key responsibility of WebSphere administrators, “performance tuning” is the process of finding ways the WebSphere environment can operate more efficiently.  This 3 day course covers performance tuning methodology, how to detect a bottleneck and common problems and solutions. After taking this class, students will be able to methodically create a stress testing plan and find bottlenecks and resolve them.

WA1849 Advanced WebSphere Application Server 7.0 Administration

This 3 day course covers some of the more advanced clustering and security aspects of a complex WebSphere environment.  After taking this course, students will be able to design a WebSphere based system that is more secure, easier to manage and performs better. Students will also be familiar with some of the new administrative and troubleshooting tools that are available with WebSphere 7.0.

WA1939 WebSphere 7.0 Problem Determination

Since troubleshooting is always a topic of great interest in our administration courses we have created this 2 day course to focus more in depth on how to resolve issues in a WebSphere environment.  Throughout the class students will learn about various advanced tools and techniques to help resolve problems in the configuration and operation of a WebSphere environment.  The class also provides details on the symptoms of many common WebSphere issues and how to resolve the issue.  Since many different products are based on the WebSphere Application Server, the issues and troubleshooting techniques covered in this class can be applied to many different WebSphere 7.0 environments.

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.

Download Stuts2Template.zip

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.


WA1853 WebSphere Process Server v7.0 Administration

Today, I was asked to compare our WA1853 with IBM’s WB722. Both are 5 days long. Both cover the basics – installation, clustering and application deployment. But, we have added a few chapters that customers have repeatedly asked for. IBM’s WB722 does not have them or covers them only lightly.

1. We have a performance tuning chapter – Chapter 17. Performance tuning is a complicated matter in a Business Process environment. We have done original research in that area that has gone into this chapter.

2. We have a troubleshooting chapter that covers most common problems – Chapter 18.

3. Chapter 16 – Process Error Recovery is crucial for companies deploying BPEL business processes. It covers what happens when a process instance fails. How to manually or automatically deal with that.

4. Chapter 19 – Routing Web Service Requests Through a Web Server is a useful one. It covers often overlooked topics, the little things you need to do to expose a web service to the outside world. They are not rocket science, but when you take care of these little things, the service offering looks professional and works reliably.

As always, we try hard to gauge what pains our clients the most. We do our best to cover those areas in our courses.

No Comments

Parallel Path Execution in WebSphere ESB 7

A mediation flow can run multiple branches in parallel but in a single thread. Basically, it uses the request with deferred response pattern. We will use an example to understand how things exactly work. But, before we get to that, let’s look at what we need to do to enable parallel processing. You will need to do two things:

1. For the Service Invoke primitives in the aggregation block, set the Invocation Style property to Async.


2. For the Fan Out primitive, choose Check for asynchronous responses after all messages have been fired. The Fan Out has to be in iteration mode for you to be able to choose that option.


Now, let’s examine an example.


Here, for all Service Invoke primitives, Invocation Style has been set to Async. For the Fan Out, Check for asynchronous responses after all messages have been fired has been selected.

The flow will perform as follows. First ServiceInvoke1 will be called immediately followed by ServiceInvoke3 (actually, the exact order of their invocation can not be determined and does not really matter). System will not wait for response from ServiceInvoke1 before ServiceInvoke3 is executed.

Since there are primitives left to be executed in both branches, the flow will then go to wait for responses to come back from the two already executed operations. This wait in the middle of the paths can not be avoided since the subsequent primitives may depend upon the output of the executed operations. After ServiceInvoke1 and ServiceInvoke3 return output back, system will then execute XSL4 and ServiceInvoke4. Without waiting for response from ServiceInvoke4, system will execute XSL2 and ServiceInvoke2. System will then wait for the responses to come back from these two Service Invoke primitives.

A Note About Deadlock

In the example above, request is sent but the system does not wait for a response. You need to be careful about the transaction boundary. Let us say that a request is sent by posting a message in a JMS queue. By default, the message will be actually posted if the transaction of the mediation flow commits. If the flow waits for a response, that will never come since the transaction is still active and the request message never went out in the first place. Long story short, you will have to post the request message in a separate transaction from the main transaction of the message flow. To do that, select the service reference of the mediation flow in the assembly diagram. Then set the Asynchronous invocation qualifier to Call.


WID v7 actually give you an error message if you setup parallel processing but do not configure the transaction boundary correctly.


Migrating Projects to WID 6.2 to 7.0

This morning, I started working on the WebSphere ESB v7.0 programming course – WA1916 WebSphere Enterprise Service Bus (ESB) v7.0 Programming Using WebSphere Integration Developer. I had to migrate a few projects from WID 6.2 to get started. I thought I will share a few interesting observations.

WID has  built in workspace migration wizard. When you bring in an old project – either through the import operation or CVS checkout – it will open the wizard automatically. In my case, I chose File > Import and then Other > Project Interchange.

I recommend migrating projects in two separate batches. First migrate the J2EE projects – that contain web services and web clients. Then migrate the business integration (SCA) modules. That will just simplify things.

Migrating J2EE Projects from WID 6.2

In WID 6.2, the J2EE projects were on a half way journey towards Java EE 5. They were J2EE 1.4 projects with some aspects of Java EE 5 thrown in – such as JAX-WS and JPA. That was done through WebSphere feature packs. Now, in WID 7, we have true Java EE 5 projects. So, what that means is, migration will involve two steps:

  1. Migrate the project structure from WID 6.2 to 7.0. This will be done by the workspace migration wizard that is started automatically when you bring the old project into WID 7 workspace.
  2. Migrate the specification level from J2EE 1.4 to Java EE 5. This will be done by a separate migration wizard.

So, let’s get started. Import the old J2EE projects (Enterprise application, web and EJB projects) into the workspace. The workspace migration wizard will start automatically after the files have been copied into the workspace. You can pretty much click Next in every screen. In the server runtime page, you will need to select a V7 server.


In my case, I selected WebSphere ESB Server v7.0. You can also select process server, if that is your runtime.

After the migration wizard finishes, if you have a JAX-WS web service in a web or EJB module, you will see an error message.


WebSphere Application Server v7.0 is not going to scan this module for JAX-WS annotations. You can enable scanning by setting the UseWSFEP61ScanPolicy property to true in the MANIFEST.MF file.

I must say, I was stumped by this. Fortunately, I could Google "UseWSFEP61ScanPolicy" which lead me to this InfoCenter page. Log story short – I had to migrate the projects from J2EE 1.4 to Java EE 5. Honestly, I did not originally consider that step, until I saw the InfoCenter page. So, in a way I am glad I saw that error message. In the next section, we will deal with Java EE migration.

Migrate Specification Level

Right click the enterprise application project and select Java EE > Specification Migration Wizard. Once again, you can pretty much click Next in every page and complete the wizard.

But alas, the error message remained. No amount of cleaning, rebuilding and re-validating got rid of it. Fortunately, I found an easy solution. Just export the projects as project interchange and then import them back in. That will get rid of the error.

Migrate SCA Modules

Import the SCA modules into the workspace. The workspace migration wizard will open. Change the server runtime to V7.0. And you are done!


No Comments

WebSphere Application Server and IBM HTTP Server Cheat Sheet for Unix/Linux

Important Commands


  1. All of the WebSphere Application Server (WAS) commands below are located underneath the <PROFILE_ROOT>/bin directory.
  2. All of the IBM HTTP Server (IHS) commands are located underneath the <IHS_ROOT>/bin directory.

Start a server

./startServer.sh <serverName>

Stop a server

./stopServer.sh <serverName> -username <userName> -password <password>

Start a node agent


Stop a node agent

./stopNode.sh -username <userName> -password <password>

Start the deployment manager


Stop the deployment manager

./stopManager.sh -username <userName> -password <password>

Obtain server status for all servers on a node

./serverStatus.sh –all -username <userName> -password <password>

Obtain server status for a particular server

./serverStatus.sh <serverName> -username <userName> -password <password>

Start IBM HTTP Server

./apachectl start

Stop IBM HTTP Server

./apachectl stop

Start IBM HTTP Administration Service (Server)

./adminctl start

Stop IBM HTTP Administration Service (Server)

./adminctl stop

Important Log Files

WebSphere Application Server

SystemOut.log (located under <PROFILE_ROOT>/<profileName>/logs/<serverName>)


access_log (located under <IHS_ROOT>/logs) – contains requests from clients (browsers)

error_log (located under <IHS_ROOT>/logs) – contains error messages, including expansions of 404s

IBM HTTP Administration Service

admin_access_log (located under <IHS_ROOT>/logs) – contains requests from WAS

admin_error.log (located under <IHS_ROOT>/logs) – contains error messages (e.., related to propagation of plugin and starting/stopping web server)

WebSphere Plugin

http_plugin.log (located under <IHS_ROOT>/Plugins/logs/<webServerName>)

1 Comment