Wrappers and non-existent classes and performance

[Benson Margulies <bi...@gmail.com>]

JAX-WS like to look for non-existent classes. This costs something, by the
time that ClassLoaderUtils.loadClass gets done making three (or is it four?)
calls to the class loader. Are wrapper classes really legitimately possibly
defined in all those different class loaders? Should I make a negative cache
that recalls the nonexistence of classes once not found?

Re: Wrappers and non-existent classes and performance

[Benson Margulies <bi...@gmail.com>]

So, it's probably not worth adding 'nobody home' caches for
repeat-creation-offenders, as opposed to advising them to go ahead and
generate  the missing items?

Re: Wrappers and non-existent classes and performance

[Daniel Kulp <dk...@apache.org>]

Per spec, we're supposed to look for the wrapper classes for all the 
doc/lit/wrapped methods.  With the RI, the classes would have had to 
exist.  The user would have had to run wsgen to create them.  (java 
first case assumed)

CXF doesn't require something like wsgen to create them.   If the 
wrappers are there, we use them.  But if the wrappers aren't there, 
we're OK with that too.  2.0.x will handle each part individually.  2.1 
uses ASM to create the wrappers in memory.  

In anycase, we definitely need to check two classloaders and possibly the 
third.  In webapp type things, they would come from the 
contextClassLoader.   In standalone type things, they would come from 
the "default" classloader.   

The third case is a bit more obscure.   Basically, if someone creates 
their own classloader to load cxf and their application, we would need 
to check the classloader that loaded the cxf classes.  That said, MOST 
of the time, the classloader that loaded cxf is one of the above two and 
thus this can be skipped.

Not sure what the forth classloader would be.

That said, the "workaround" would be to have the user run the java2ws 
tool (on 2.1, java2wsdl on 2.0) with the appropriate flag to have it 
generate the wrappers like wsgen would do.   Thus, the classes should be 
available.

Dan



On Tuesday 01 April 2008, Glen Mazza wrote:
> Hmmm...why would it try to look for a non-existent class?  Or, do you
> mean, it is looking for existent classes, but using the wrong
> classloaders for them?
>
> Glen
>
> Am Dienstag, den 01.04.2008, 13:25 -0400 schrieb Benson Margulies:
> > JAX-WS like to look for non-existent classes. This costs something,
> > by the time that ClassLoaderUtils.loadClass gets done making three
> > (or is it four?) calls to the class loader. Are wrapper classes
> > really legitimately possibly defined in all those different class
> > loaders? Should I make a negative cache that recalls the
> > nonexistence of classes once not found?



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Re: Wrappers and non-existent classes and performance

[Glen Mazza <gl...@verizon.net>]

Hmmm...why would it try to look for a non-existent class?  Or, do you
mean, it is looking for existent classes, but using the wrong
classloaders for them?

Glen

Am Dienstag, den 01.04.2008, 13:25 -0400 schrieb Benson Margulies:
> JAX-WS like to look for non-existent classes. This costs something, by the
> time that ClassLoaderUtils.loadClass gets done making three (or is it four?)
> calls to the class loader. Are wrapper classes really legitimately possibly
> defined in all those different class loaders? Should I make a negative cache
> that recalls the nonexistence of classes once not found?