| Problems with context classloader when running Eclipse as headless antRunner [message #334220] |
Mon, 26 January 2009 23:32 |
 Mike Morearty
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
I'm struggling with context ClassLoaders when running Eclipse headless --
that is, when launching with "-application org.eclipse.ant.core.antRunner".
When running Eclipse the regular interactive GUI way, Eclipse sets the
context classloader to a special classloader that understands OSGi, which
makes it much easier to call third-party library code that relies on
context classloaders. This is explained in detail here:
http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhan cements#Context_Class_Loader_2
-- but the gist of it is, the context classloader is a classloader that
will figure out which OSGi bundle is currently "in scope," and use that
bundle's classloader.
But when running as org.eclipse.ant.core.antRunner, the context
classloader is different. This is documented -- the context classloader
is set to AntClassLoader (
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse. platform.doc.isv/reference/api/org/eclipse/ant/core/AntRunne r.html
), and is apparently done deliberately, although I'm not really clear on
the reasons ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=21793#c5 , for
example, mentions that AntRunner sets and restores the context
classloader).
But the net effect of the way antRunner sets the context classloader is
this:
Code that runs fine when Eclipse is running interactively,
does not run correctly in antRunner!
This seems like a bug to me. In general, a plug-in should work the same
no matter how the app was run (within reason, of course -- e.g. launching
as antRunner means UI calls will fail, for example).
I can think of two possible workarounds:
1. Use the "org.eclipse.ant.core.extraClasspathEntries" extension point to
add my plugin to the list of classes that are visible from AntClassLoader.
This does NOT work for me, because it gets right back into the
classloader hell that OSGi was meant to solve in the first place: When I
tried this, suddenly a bunch of Apache libraries were visible to everyone,
and lots of other stuff started to fail.
2. Call Thread.currentThread().setContetClassLoader() explicitly whenever
I am about to call into one of these libraries. I think this is going to
work for me, but it is tedious and error-prone.
I am going to do #2 for now, but this behavior seems like a bug to me.
What do you think?
Thanks,
Mike Morearty
Sr. Computer Scientist
Adobe Systems, Inc.
|
|
|
Powered by
FUDForum. Page generated in 0.03451 seconds
] 
Search
Help
Register
Login
Home
