Brett,
Yes, There are two ways
Put the customization section into your schema in the wsdl,
<xsd:annotation>
<xsd:appinfo>
<jxb:globalBindings collectionType="indexed"/>
</xsd:appinfo>
</xsd:annotation>
or change it to an external style, and feed the 'binding file' to the
> wsdl2java -b $YOUR_BINDNIG_FILE
Let me know if it works for you
Cheers,
James
James,
Ok, it seems to be doing almost what I need. I still get the warnings
during java2wsdl because java2wsdl is looking for the wrapper bean classes
but they don't exist yet! _It_ is the tool that creates them. Anyway, if I
allow it to create them (after all of the warnings) and compile them AND I
make those classes available during wsdl2java generation, I seem to get
properly wrapped client bindings.
However, this is a method on my SEI:
public JobMetadata[] getJobMetadataByGroup(String jobGroup);
And this is the generated client-side signature:
public List<JobMetadata> getJobMetadataByGroup(String arg0)
As you can see, it converted my array of JobMetadata objects into a List.
Is there some way to avoid this?
Thanks,
Brett
On 7/30/07 11:31 PM, "James Mao" <[EMAIL PROTECTED]> wrote:
The reason it generate the BARE, is because the WSDL is in BARE style,
the reason WSDL is in BARE is because the java2wsdl can not load the
wrapper bean classes,
You can append the wrapper bean annotation in your SEI, so the tools
knows where to load the wrapper beans, or the tools will go to the
default location, i guess the default values is the jaxws sub-package of
the SEI package.
My invocation to generate WSDL looks like this:
java2wsdl -verbose
-o scheduler.wsdl
-cp scheduler/bin
-t scheduler.provider.ziptie.org
-d scheduler/META-INF
org.ziptie.provider.scheduler.IScheduler
But curiously, even though I¹m only generating WSDL I get warnings like
these:
INFO: Creating Service {scheduler.provider.ziptie.org}ISchedulerService from
class org.ziptie.provider.scheduler.IScheduler
Jul 30, 2007 10:10:10 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
isWrapperBeanClassNotExist
INFO: Tring to load wrapper class
org.ziptie.provider.scheduler.jaxws.GetFilter
This stacktrace confirmed what i said above.
Jul 30, 2007 10:10:10 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
getWrapperClass
WARNING: Can not load wrapper class
org.ziptie.provider.scheduler.jaxws.GetFilter, please check the
@RequestWrapper or @ResponseWrapper and also check the class is in your
classpath
I don¹t really want wrappers generated during this phase (they¹re generated
again when I run wsdl2java), but I don¹t see any way to suppress this
generation.
You are right, they are annoying, we are working on a new tool , dont'
know the name , maybe 'java2ws',
With java2ws you don't need to java2wsdl <--> wsdl2java, this is the one
of the main goals.
Cheers,
James.
Thanks for any help you can provide. I am running 2.0.
-Brett
