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
>>
>>
