views:

143

answers:

2

I'm writing a testing Framework which is starting a GUI Application. To be able to test this GUI in the case of an SWT application I need to know it's display. In general, this display is loaded by another classloader, therefore I'm using the method findDisplay(Thread t) of the swt Display class by reflection to accomplish this task. My code looks something like this:

Thread[] threads = new Thread[10];
Thread.enumerate(threads);
Object foundObject = null;
for (Thread t : Arrays.asList(threads)){
    foundObject = null;
    Class<?> clazz = t.getContextClassLoader().loadClass("org.eclipse.swt.widgets.Display");
    final Method method = clazz.getMethod("findDisplay", Thread.class);
    foundObject = method.invoke(null, new Object[] {t});
    if (foundObject != null) {
        System.out.println("yeah, found it!");
        break;
    }
}

In my opinion this should find every Object of type Display in the current thread group. However I don't get any for the texteditor RCP example although the GUI is starting up perfectly.

Any ideas what is going wrong or how I can debug this in a reasonable way?

Thanks for your help

A: 

I figured out what the main problem was: The ContextClassloader had nothing to do with the classloader who actually loaded the classes.

To resolve my problem I took care of having the classloader which loads the swt display class both in the hierarchy of the RCP program and the hierarchy of my framework. This was possible by using the java extension classloader. (I couldn't use the application classloader since my RCP application doesn't work with it as parent, I haven't figured out yet why) It was then just a matter of adding the swt.jar to the java.ext.dirs property.

HerdplattenToni
A: 

If you are using Eclipse RCP then maybe you can use:

PlatformUI.getWorkbench().getDisplay()

Suraj Chandran