> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Tuesday, September 24, 2013 4:23 PM > To: dev@cloudstack.apache.org > Subject: RE: VmWare SDK to vijava > > So this discussion took a big turn that I did not expect. I am very strongly > against creating a "plugin" layer just to interface with VmWare. I appreciate > both the effort from Darren and Hugo and each hold some merit. I think we > should discuss this out and drive a consensus rather than spending time to > create "plugin" layers and such. > > For me, I prefer going directly to wsdl because the helper layer (both vim25 > and vijava) is so thin that it's not a lot of effort to reproduce. Going > directly > to wsdl has the following advantages: > - We don't have to worry about upgrades in the helper libraries. Look at > what happened on 4.2 vim25 upgrade and the change in hidden behavior > changes that caused lots of bugs. It just doesn't seem to be worth the time > to deal with third party helper libraries for the small amount of code gain. > - With wsdl, we can generate with different package names so that using > two different versions of wsdls can have two different set of stub classes so > we avoid using java class loaders to distinguish between the two.
I want to elaborate specifically on this point a little bit. In a production deployed cloud that has been around, there's bound to be hypervisors of different versions. We have that problem with XenServer because it is version that's been supported by CloudStack the longest. CloudStack deals with the different versions of the same Hypervisor by writing two different ServerResources (they might share a common base of course). However, if the client stubs the different ServerResources talk to are also of different versions but with the same name, then we have to work on confining different versions of the client stubs to different class loaders. That's a lot of effort to do something simple. Instead, we can simply designate a different package name when generating from the wsdl (assuming the different versions of client stubs is due to wsdl versioning differences when interfacing with different versions of hypervisor) and have the ServerResources just refer to the different client stubs generated. Hence, I prefer generation directly from wsdl. --Alex
