Just and idea, as I don't konw the internal CXF code...

Maybe the classloader is wrong in the current thread. The recommended way to
get the classloader in a multithreaded environment is to call
*Thread*.currentThread().getContextClassLoader(),
while getClass().getClassLoader() wasn't recommended.




On Thu, Jul 10, 2008 at 14:47, Stopp, Bryan <[EMAIL PROTECTED]>
wrote:

> Brad,
>  Yes, what you're suggesting is possible. However, even with
> parent-last (WAR-first) class loading, the error still shows up.
>
> -Bryan Stopp
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad
> Sent: Wednesday, July 09, 2008 6:23 PM
> To: [email protected]
> Subject: Re: java.lang.IncompatibleClassChangeError in WebSphere 6.1
>
> Hi Bryan,
>
> complete shot in the dark, been a long time since I have done any
> WebSphere work but I seem to remember it used to be possible to change
> the classloader behavior on a per-application basis. Maybe you can
> change the classloading for your application so that it picks up the
> JAR from your WAR without delegating to the parent classloader?
>
> Just a guess really but you never know.
>
> Brad
>
> On Wed, Jul 9, 2008 at 10:27 PM, Stopp, Bryan
> <[EMAIL PROTECTED]> wrote:
> > All,
> >
> >
> >
> >   I have found several nabble and archive instances of this error
> being
> > reported, but I'm going to try again from a different angle.
> >
> >
> >
> > Problem: in WebSphere 6.1 an Error is thrown
> > (java.lang.IncompatibleClassChangeError) when running CXF 2.1.1.
> >
> >
> >
> > A supposed "solution" is to put the wsdl4j.jar file in the endorsed
> > directory or in a shared library. However what I'm trying to find out
> > is: Does anyone know what is causing this problem? I haven't seen
> > anything but speculation and no real answer as to the cause. Why does
> > the error appear when the JAR is bundled within the WAR but not when
> the
> > jar is on the Server's classpath?
> >
> >
> >
> > A better question I have is: Is there another solution that doesn't
> > require that I define a global resource which could cause conflicts
> with
> > other applications? Either solution limits me to using a specific
> > version of this jar for all applications which are on the server; and
> > neither of which may be considered a valid option by my sys-admins.
> >
> >
> >
> > Any help on this would be greatly appreciated. Thank you.
> >
> >
> >
> > -Bryan Stopp
> >
> >
> >
> >
> >
> >
> > PRIVILEGED AND CONFIDENTIAL
> > This email transmission contains privileged and confidential
> information intended only for the use of the individual or entity named
> above.  If the reader of the email is not the intended recipient or the
> employee or agent responsible for delivering it to the intended
> recipient, you are hereby notified that any use, dissemination or
> copying of this email transmission is strictly prohibited by the sender.
> If you have received this transmission in error, please delete the email
> and immediately notify the sender via the email return address or
> mailto:[EMAIL PROTECTED]  Thank you.
> >
> >
> >
> >
>
>


-- 
Bryce

Reply via email to