cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: VmWare SDK to vijava
Date Mon, 23 Sep 2013 20:08:26 GMT
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.  


> On Sep 23, 2013, at 11:25 AM, Min Chen <> 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 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
> Thanks
> -min
>> On 9/22/13 7:59 PM, "Darren Shepherd" <> 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 <> 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 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 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

View raw message