How does the classloader for plugins differentiate from the standardjava classloader

Hello everyone

I'm currently developing a custom transformation plugin. This code
uses Apache CXF to do some webservice calls. The code works if I
execute it outside of Kettle but dies with a NullPointerException as a
plugin. I have debugged the CXF code that gets executed and to me it
looks like it loads "some" classes from "somewhere" "somehow".
I have no detailed information as the code in question isn't
documented. I have already asked at the CXF mailinglist if a custom
classloader could somehow break the CXF code but haven't got a answer
some far.

To my understanding a Kettle plugin is executed with a custom
classloader in it's context, so I suspect, that this may the root
cause of the problem. So my question is: does the custom classloader
of Kettle does something different from the standard java classloader?
Does it have some restrictions to be aware of?

I understand that this is a very unspecific question but I think if I
could provide the CXF developers with some more informations what the
context of the bug (and to me, this is a bug, as code shouldn't
simeply die with a NullPointerExecption) I can somehow solve my
problem. So any assumption, no matter how vague, would help.

Regards
Martin Thurau

--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com.
To unsubscribe from this group, send email to kettle-developers+unsubscribe (AT) g...oups (DOT) com.
For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en.

Hi Martin,

did you try to catch the "Throwable" excpetion instead of the normal "Exception"? The Throwable exception is able to catch even the NoClassDefFound exception that I think may be your problem!

regards.

Gabriele.


________________________________
Da: Martin Thurau <martin.thurau (AT) gmail (DOT) com>
A: kettle-developers <kettle-developers (AT) googlegroups (DOT) com>
Inviato: Mercoled

Kettle's Plugin Classloaders are different in that they're "inverted" or
self-first. A plugin's classloader will first try to find a class within
itself and look up to the parent classloader only when it's not found. This
allows us to supply a different version of a particular library by placing
it in the plugin's local lib folder.

I'm suspect that this would cause an issue with CXF as it is very similar to
how most application servers isolate webapps. Though if it is you may have
luck setting the Thread's context classloader temporarily to your plugin
classloader:

Classloader originalClassloader =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(MyPluginClass.class.getClassLoader());
....//Execute library code
Thread.currentThread().setContextClassLoader(originalClassloader);

-Nick B

On Wed, May 11, 2011 at 6:16 PM, Gabriele <icsj7 (AT) yahoo (DOT) it> wrote:
[color=blue]
> Hi Martin,
>
> did you try to catch the "Throwable" excpetion instead of the normal
> "Exception"? The Throwable exception is able to catch even the
> NoClassDefFound exception that I think may be your problem!
>
> regards.
>
> Gabriele.
>
> ------------------------------
> *Da:* Martin Thurau <martin.thurau (AT) gmail (DOT) com>
> *A:* kettle-developers <kettle-developers (AT) googlegroups (DOT) com>
> *Inviato:* Mercoled

Yes, this works for me. I have added to following statement before
creating my WS-Client and the error is gone:

Thread.currentThread().setContextClassLoader(getClass().getClassLoader());

This seams to be an issue with Apache CXF 2.4 since other users had
similar problems when using CXF in a context where the classloader was
something non-default. So it wasn't Kettles fault ;-)
Thank you for the information.

Regards
Martin

On May 12, 6:57