Swing Application failed to load imageicons when launched from Robot

[GoogleCodeExporter]

Hi,

When a Swing application launched from Robot Framework, it fails to locate
the images bundled inside the application jar. 

But when the image icon is stored locally in the Robot Test libraries
folder (where jvmconnector located), the SUT could load the image icon when
launched from Robot.

This has been observed in automating JWS as well in classic (locally
installed) Swing application.

Below is the excerpt of the statement loads the image icon part of the
Swing Application

-------------------------------------------------------
ClassLoader cl = CfUtil.class.getClassLoader();
if (cl != null) {
    url = cl.getResource(resPath);
} else {
    url = ClassLoader.getSystemResource(resPath);
}
}
return new ImageIcon(url, iconName);
------------------------------------------------------

The issue looks to be the Robot (jvmconnector, swing library etc.)
creates/has a separate java Classloader which overrides the class search
path of Application Classloader.

Please help me in resolving this issue.

Thanks.

With regards
Arul

Original issue reported on code.google.com by arulraj...@gmail.com on 20 Apr 2010 at 4:08

[GoogleCodeExporter]

This issue looks to be very critical as many application fails due to change in 
the
Classloader. I suspect the ApplicationLauncher.py library loading mechanism 
using
local classloader creating this problem.

Please have a look as soon as possible.

Original comment by arulraj...@gmail.com on 23 Apr 2010 at 5:49

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

What versions are you using? Are you using ApplicationLauncher or 
RemoteApplications?
We checked the jvmconnector code and we do not change any class loaders 
directly in
our code. Of course that could happen in some of the libraries we are using.

Original comment by jpran...@gmail.com on 23 Apr 2010 at 9:02

[GoogleCodeExporter]

Thanks for the reply.

Im using ApplicationLauncher.py as we are migrating the existing TCs to JWS 
since
re-writting with new RemoteAllication would need more effort.

This issue is happening in all dynamic loading scenarios.

below is the excerpt where the dynamic class loading is failing
-----------------------
Class cls = Thread.currentThread().getContextClassLoader().loadClass(className);
return cls.newInstance();
-----------------------

Thanks.

Original comment by arulraj...@gmail.com on 23 Apr 2010 at 10:16

[GoogleCodeExporter]

Is this issue still valid? 

Have you had time to test does this occur with the RemoteApplications? Please 
consider using the RemoteApplications as the ApplicationLauncher is not further 
developed. 

Is that dynamic class loading code from your application?

Original comment by jpran...@gmail.com on 17 Aug 2010 at 12:29

[GoogleCodeExporter]

Original comment by jpran...@gmail.com on 17 Jan 2011 at 6:43

• Changed state: Pending

[GoogleCodeExporter]

Closing this issue for lack of information

Original comment by janne.t....@gmail.com on 30 Aug 2011 at 10:56

• Changed state: WontFix