In the past, I’ve gone and de-constructed WebSphere Process Server stack traces in an example of problem determination. Now, I’ll talk about what I do when WebSphere Integration Developer goes crazy.
A typical WebSphere Integration Developer exception consists of either a builder error pop up dialog or an issue when trying to open an editor. You’ll see the standard eclipse error dialog with some cryptic message. When this happens to me, I try the following steps:
Regenerate the J2EE App, EJB and Web projects
Sometimes there is an error in these generated artifacts. What I first do is a clean build via the build menu, clean all. This is supposed to flush the internal state of the eclipse builders and force them to recreate all artifacts from scratch. As the versions have progressed, this has gotten better but it’s not perfect.
Should the problem continue, I will switch to the resources view and manually delete these generated projects. Once they’re gone, I will do a clean-build. Since the files are physically deleted, theres no worry about the builders maintaining internal state.
Restarting WID
Sometimes, all it takes is a simple restarting of the tool and builder errors can disappear.
New Workspace
In WID v6.0.2.3 I rarely do this anymore. I would export my current workspace as a Project Interchange file (IBM speak for a .zip file). Then I would start a new workspace and import the PI. This resolves issues with corrupted workspaces that ravaged the v6.0 GM version of the tool.
Usually, these two solutions will resolve random errors. Sometimes though, your tool is completely screwed up and you can’t even get the Business Integration Perspective to appear. This usually occurs after the first time the product is installed or when a fix pack (or add-on product like WebSphere Business Services Fabric) is installed. There are two methods of fixing these kinds of errors:
WID.EXE -clean
There is a command line option when you start WID called ‘clean’. To explain clean, we need to take a step back and understand how WID is package. WID is built on top of both eclipse and Rational Application Developer. It does this by providing a set of plug-ins that extend the eclipse platform. Eclipse then needs to index these plug-ins to determine dependencies and capabilities. Sometimes, the eclipse index is out of sync with the file system. Clean forces eclipse to rebuild this index. It will take about 5-10 minutes to start the tool as this work is performed but it will usually resolve missing editors.
WID.EXE -initialize
This is another internal eclipse command line option that tells the platform to rebuild that the plug-in caches. I normally do a clean followed by an initialize.
Finally, if neither of these solutions resolve your problem, you can take a look at the WID .log file and see the exception. The log file is contained at <workspace_location>/.metadata/.log . If you are very lucky, it may contain relevant data.
So you now know my WID secrets on fixing tooling time errors. I hope it will save you some time in the future.
There’s a trick in 6.1 to quickly delete the generated J2EE projects. Right-click your module without leaving the BI view, then select Close Project. This deletes all the generated projects. Next, reopen it and they will be regenerated.
Those are nice tips on WID. Thank you. I have one question.
I use Windows XP SP2 + IBM DB2 9.1 + WID 6.1.
We have a requirement to store Japanese characters(that includes characters from Japanese language sets like Kanji, Hiragana, Katakana) + English characters in DB2. When the user enters some data (that includes Japanese characters + English characters) on the client side then that data flows through the application calls that route the data through the BPEL process and then into the database.
Say we need to do write some logic using various BPEL constructs available in WID like choice activity, receive activity, reply activity, receive choice, correlation sets etc. then will there be a problem when we use such logic using Japanese characters ? How will WID behave in cases where your BPEL constructs work on Japanese characters ? Do we have to change the codeset/codepage of WID/WebSphere for working with Japanese characters ?
Please clarify.
The artifacts that are generated by WID and consumed by process server are UTF-8 (Unicode) encoded. You should be able to you use your Japanese character sets without issue.
If you find that you DO run into something, then open a PMR for it because everything should be i18n.
In the future, please use the newsgroups for questions. I monitor them obsessively and theres more opportunity for responses than here.
@Richard,
Good tip. This works in WID 6.0.2.x as well, but you need to switch to Physical Resources view to access the ‘Close Project’ menu item.
Oh my god! What kind of an enterprise development is this that you people don’t even have a reliable IDE!?!
I don’t really want to think about your servers.
Who told that Microsoft stuff means “did you tried restarting”?
Hi Peter,
While I agree that the development environment does have bugs, I wonder what IDE you are comparing WID to? Lets remember that J2EE IDE’s have been around for a very long time with a very large user base. I’ve seen large in WID between 6.0, 6.0.2, 6.1 and 6.2 which comprise about 3 years of development. If the product stays relevent for another 7, then I’d suggest a more direct comparison to ‘simpler’ IDEs.
-Dan