How'd you know about the post processing? I generated the stubs and it compile perfectly and ACS compile against the stubs too. I have no clue if it work as I never ran it though. One thing I ran into was that you had to generate for jaxws 2.1.
Darren > On Sep 23, 2013, at 11:25 AM, Min Chen <min.c...@citrix.com> wrote: > > When I upgraded vmware sdk from 4.x to 5.1 before, I looked into the build > script used by Vmware published SDK. It seems that besides normal jawxs > generated client stubs from wsdl, Vmware sdk published build script has > another post processing done on VimService.java class generated. The post > processing class has no source code, only binary bundled with Vmware SDK. > If we want to generate client stubs ourselves from WSDL, we may need to > delve in to see why that post processing is needed for VimService.java. > > Thanks > -min > >> On 9/22/13 7:59 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >> >> I was looking at the vmware jar and realized it's just a jaxws generated >> client stubs. I'm sure this has been discussed before, so I'm curious why >> we can't just download the wsdl and generate the stubs ourselves? I >> assume >> we can't distribute the wsdl's, so we can just check in the java code >> minus >> the wsdl. That should work fine at runtime. I downloaded the sdk and >> generated the client with the below command and its 100% compatible with >> the vim25.jar >> >> ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p >> com.vmware.vim25 vim25/vimService.wsdl >> >> Darren >> >> >>> On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers <h...@trippaers.nl> wrote: >>> >>> Hey all, >>> >>> This is something we wanted to do for a long time, but never got started >>> as far as i know. With some time on my hands i've made some progress on >>> this. I just pushed the branch vmwaresdk-to-vijava to git. In this >>> branch >>> i've changed the poms to use the vijava library (version 5.1) and i've >>> started fixing all resulting compile errors. >>> >>> It is not a complete drop in replacement, but apparently just enough to >>> make it work with a few changes. The major issues i've encountered so >>> far >>> by working my way through VmwareResource.java are >>> * changes to enums, slightly different naming convention for the values >>> * vijava used arrays where vmware sdk uses lists >>> * changes names of exceptions. >>> >>> I've fixed all compile issues in VmwareResource.java at the moment and i >>> will keep at it. If somebody want to pitch in, feel free. Just pick a >>> file >>> with compile errors and fix it :-) >>> >>> So far i've not focussed on the potential benefits of the vijava >>> library, >>> let's get it compiling first so we can do some testing with the new >>> library. >>> >>> Is anybody planning some major work on the vmware stuff in CS? If you >>> do, >>> please let me know, so we can coordinate otherwise this will be a >>> bother to >>> merge into master eventually. ;-) >>> >>> Cheers, >>> >>> Hugo >
