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 [EMAIL PROTECTED] http://www.dankulp.com/blog
