cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: JAXB is not sitting well in an OSGI /eclipse env...
Date Mon, 08 Jan 2007 13:15:58 GMT
When? I don't see any message in recent history on the JAXB mail list from
you. Might be worth a follow up/reminder which also asks about the property
you found and seeking an explanation - I know I'd be interested too.

On 1/8/07, Beaurpere, David <David.Beaurpere@iona.com> wrote:
>
> Did that... no reply yet...
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 08 January 2007 12:40
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: JAXB is not sitting well in an OSGI /eclipse env...
> >
> > It might be good to ask your question on the JAXB users list. It is
> > generally a very helpful place, especially for questions of this sort.
> >   Cheers,
> >   Dan
> >
> > On 1/8/07, Beaurpere, David <David.Beaurpere@iona.com> wrote:
> > >
> > > 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
> > >
> > >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message