It's all about the answers!

Ask a question

Can't connect to Jazz Server in WAS 7.0

Stephen McDonald (2634) | asked Apr 20 '12, 2:37 p.m.

I'm trying to connect to a Jazz server on a web application using WAS 7.0 and getting the error listed below. When I use the same code as stand alone Java, it works fine, but that doesn't help me out, I need it to work in the web app. I have all the RTC Plain Java jars in WEB-INF/lib (I think it has something to do with not being able to load these properly in WAS)

Here is the Error I am getting:
4/20/12 14:31:31:984 EDT] 0000002c SystemErr R Badly configured client. Missing a foundation component tag.
0000002c SystemErr R at
0000002c SystemErr R at
0000002c SystemErr R at
0000002c SystemErr R at rtc.GetRTC.login(
0000002c SystemErr R at rtc.GetRTC.tryToConnect(

These are the two methods I am using:

public static void tryToConnect(){

System.out.println("started up");
try {
IProgressMonitor monitor = new SysoutProgressMonitor();
ITeamRepository repo = login(monitor);
} catch (TeamRepositoryException e) {
System.out.println("Unable to login: " + e.getMessage());
} catch (Throwable t){
} finally {
if(TeamPlatform.isStarted()) //eliminate the errors in console from trying to stop


public static ITeamRepository login(IProgressMonitor monitor) throws TeamRepositoryException {
ITeamRepository repository = TeamPlatform.getTeamRepositoryService().getTeamRepository(url);

LoginHandler lh = new LoginHandler(username,password);
monitor.subTask("Contacting " + repository.getRepositoryURI());

} catch (Throwable t) {
monitor.subTask("Couldn't connect");
return repository;


Any help would be greatly appreciated.

Thanks in advance,

5 answers

permanent link
Martha (Ruby) Andrews (3.0k44051) | answered Sep 04 '12, 6:10 p.m.
One more piece of information on this issue.

Setting PARENT_LAST as the class load policy might not work  if your application also contains 3rd party libraries that rely on WAS classes.

WAS support suggested these steps for loading the RTC Plain Java Client classes with a different class loader than the third party classes:
Package the RTC java client library as a server scoped shared library.
Make the shared library an isolated shared library by checking the "Use an isolated class loader for this shared library" checkbox in the Integrated Solutions console.
Associate the shared library with your application.
There should now be no need to use PARENT_LAST classloading.

For information on isolated shared libraries, see

For information on creating a shared library, see:

Martha (Ruby) Andrews
Jazz L3 Developer

Ritchie Schacher - IBM commented Sep 28 '12, 9:55 a.m. | edited Sep 28 '12, 9:55 a.m.

For reference, this is also being tracked in the following work item:
Error running plain java app in WAS (76455)

Joseph Mao commented Oct 28 '12, 9:08 p.m.

To avoid this problem, with use RTC client API as isolated shared library, the user application still "REQUIRED" to use PARENT_LAST classloading.

permanent link
Nick Edgar (6.5k711) | answered Aug 31 '12, 12:33 p.m.
edited Aug 31 '12, 12:33 p.m.
For others hitting this, in addition to trying Stephen's answer above, you can try seeing whether WebSphere (or someone else) is configuring a different Eclipse/Equinox extension registry than the "standalone" one we try to set up as part of TeamPlatform.startup().  Check the result of:


before calling TeamPlatform.startup().

permanent link
Simon Huber (1) | answered Jul 04 '12, 1:55 p.m.
I think the last post is long ago, but probably for anyone is this answer useful. 
I had the same problem as i use the RTC Plainlibs in Jython. (To extend an application(server-side) without compiling the code witch use the rtc). 

The fail for me was that i don't have the control, witch classloader loads the Plugin.xml - Files. (And as a developer i like to have the control ;D )

So i must correct the class of IBM. 
The Class StandaloneExtensionRegistry has a code line in the constructor: 

I changed this to: 

 ClassLoader loader = ClassLoader.getSystemClassLoader();
 extensionFiles = loader.getResources("plugin.xml"); 

And add the *.Jars to the SystemClassLoader - path. 

Perhaps this is useful for anyone. 


(Veersion 3.. of Plainlibs) 

permanent link
Stephen McDonald (2634) | answered Apr 23 '12, 10:44 a.m.
Thanks for the reply Nick, I've now got it connecting.

Here is what I changed for anyone else having this same problem:
- I removed the javax.servlet jar from my build path
- I changed the classloader mode and policy. (Right Click on the EAR -> Java EE -> Open WebSphere Application Server Deployment, go to Application section and make Classloader mode: PARENT_LAST and WAR classloader policy: APPLICATION)

I found this thread useful:

Nick Edgar commented Apr 23 '12, 11:07 a.m. | edited May 27 '13, 2:50 p.m.

Good to hear that you were able to get it working. I wonder whether there's some way to specify that classloader mode in your WAR file's manifest, rather than having to configure it manually.

permanent link
Nick Edgar (6.5k711) | answered Apr 21 '12, 11:32 a.m.
It's complaining because it can't find the following extension:
	<extension point="">

<componentConfiguration id="" version="4.0" clientCompatibilityVersion="4.0RC2"/>

(or similarly for 3.x). This lives in the plug-in. You must already have that plug-in available, though, or it wouldn't be able to resolve any of the classes from that plug-in, like

You will also need the plug-in, which has a similar extension for the RTC component configuration (which is distinct from Foundation's). But the error would be different if that was the problem.

So it looks like the plugin extension registry is not properly initialized. Your code is doing everything it should, though, i.e. calling TeamPlatform.startup as early as possible. The only way it could be done earlier is if you called it in a static initializer in the first loaded class in your WAR.

When running as standalone Java (i.e. outside an OSGi/Equinox container), TeamPlatform.startup does various initialization, including poofing up a fake-o extension registry by scanning for all plugin.xml files on the classpath. When running under Equinox, this is skipped since Equinox is then responsible for managing the extension registry.

What do you get if you print out (before TeamPlatform.startup()) the results of:

The call to RepositoryPackage.eINSTANCE.eContents() used to be needed as a workaround in the past (especially when multiple classloaders were in play, like in a web container). I don't think it is now, but it doesn't hurt, so I would leave it in for now until you get things working, then can try without.

If you're able to run under debug, try setting a breakpoint in and see whether initializeRegistry() gets called.

It's likely due to classloader differences when running under WAS. Others seem to have worked around the problem by tweaking WAS class loader order settings, e.g. see and

There are several other topics discussing this in the forum, but no one clear solution.

Your answer

Register or to post your answer.