cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Beaurpere, David" <David.Beaurp...@iona.com>
Subject RE: JAXB is not sitting well in an OSGI /eclipse env...
Date Mon, 08 Jan 2007 12:09:19 GMT
Actually no as simple as that, no class loader is called...

The "injector" class from the JAXB impl really goes out of it way to
"force define" classes: it retrieves the Method handle from
ClassLoader.class, reset its accessibility settings and call invoke on
it directly (see the snippets at the end)

Now, I have no idea why JAXB seems to believe that it needs to go to
such extremes to load classes (apparently generated on the fly) that the
classloader knows about already.

That said, I came across a work around: setting the env var
"com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" will cause JAXB to
avoid that code completely. Not too sure of the implications regarding
the performance though.


#############################
....
    private static final Method defineClass;
    private static final Method resolveClass;
....
    defineClass =
ClassLoader.class.getDeclaredMethod("defineClass",String.class,byte[].cl
ass,Integer.TYPE,Integer.TYPE);
    resolveClass =
ClassLoader.class.getDeclaredMethod("resolveClass",Class.class);
....
    // TODO: check security implication
    // do these setAccessible allow anyone to call these methods
freely?s
    defineClass.setAccessible(true);
    resolveClass.setAccessible(true);
...
 
(Class)defineClass.invoke(parent,className.replace('/','.'),image,0,imag
e.length);
    resolveClass.invoke(parent,c);
....
#############################


> -----Original Message-----
> From: Conrad O'Dea [mailto:conrad.odea@iona.com]
> Sent: 08 January 2007 07:34
> To: cxf-dev@incubator.apache.org
> Subject: Re: JAXB is not sitting well in an OSGI /eclipse env...
> 
> David,
> 
> On 3 Jan 2007, at 11:05, Beaurpere, David wrote:
> 
> > Guys,
> >
> >
> >
> > Sorry for the previous mail it was sent by mistake before being
> > ready...
> >
> >
> >
> > I am writing some plugins for eclipse that uses APIs based on the
cxf
> > tools framework and wsdl model.
> >
> >
> >
> > I have a frustrating situation here where calls to the
> > org.apache.cxf.wsdl11.WSDLManagerImpl (and its multiple calls to
> > "JAXBContext.newInstance(...)") causes an avalanche of
> > "java.lang.LinkageError: duplicate class definition:..." error being
> > spit out. I have copied a sample stack trace and the config props I
am
> > getting at the end of this mail.
> >
> > I am not really familiar with the detailed workings of JAXB and I
have
> > no idea why the API is calling systematically "defineClass(...)"
> 
> ClassLoader.defineClass will be called as a result of loadClass.  If
> the classloader does not find the desired class in its current
> context it will locate the bytes of the class file and call
> defineClass to create an instance from the bytes.  Although it's lost
> in the trace provided, I would expect that it is loadClass that is
> being invoked by JAXB and that defineClass is being called as a side-
> effect.  In other words, JAXB may not be doing anything odd.
> 
> This LinkageError typically occurs when a customized classloader
> attempts to load (and define a class) that is already loaded in the
> ClassLoader's context. This can happen if a classloader overrides
> loadClass but is not checking to see if the class is already loaded.
> 
> > I thought I would write to this list before getting to the JAXB one.
> > Just in case there's a chance that something can be done on your
side
> 
> rgds
> Conrad


Mime
View raw message