As I tweeted last week, there would be a big announcement when the open source VI Java API gets 20,000 downloads. It hit target yesterday. To celebrate it, I decide to release the code generator for the API, which William (@lamw) rated as “awesome.”
If you’ve had a chance to use vSphere Web Service SDK, you must know the PropertyCollector is very hard to use. It takes a newcomer quite some time to learn how to use it, and even more time to learn to use it effectively. Luckily, you no longer have to if you use the open source vSphere Java API (a.k.a. vijava) because it has encapsulated the PropertyCollector behind these newly added getter methods of the managed object types.
If you have read my previous article on vSphere security model, you know how it works. Still, you may wonder what roles a particular user may have, as asked in a recent email from one of my former VMware colleagues.
In an operating system, a user is assigned to a group or multiple groups therefore granted a certain permissions. In vSphere, a role is simply a set of privileges and that is it. It’s natural to think of a role as a group sometimes, but it’s really not.
Last month a question was raised in our open source vSphere Java API forum regarding an exception during HostSystem.getSummary() method call. As you can see from the stack trace, the actual exception was “org.dom4j.DocumentException.”
Upon hearing about my leaving VMware, quite a few members in the community sent me emails or tweets asking about the future of the API. Most of them have built products or automation scripts using the API, therefore would like to see the continuous success of the open source project. I am sure there will be more inquiries coming without this post.
It’s been one plus month since I pushed out the beta code which has since been downloaded more than 700 times. As promised, I am happy to announce the GA of VI Java API 5.0 today. This is the fourth major release after 1.0, 2.0, and 2.1 which are all shipped on time. Predictability is important for commercial products, even so for open source projects like this. I think we’ve demonstrated it in the past three and half years since the first release in May 2008.
Session management is a very important part of vSphere management, especially when scalability is involved. I’ve blogged about this in my previous posts (1, 2). If you haven’t read them yet, it’s high time to do so.
In this article, I am going to share with you a new finding while helping a development team. By default, an idle session is terminated by vSphere server after 30 minutes. The team found that it’s not totally true. They use several types of sessions for different purposes. Two of the sessions remain live even after the 30 minute default while others are gone.
It’s a known bug in VI Java API that it did not escape strings to be included within a XML tag. The potential risk, although very very rare, is that it can blow the de-serialization of a request on the server side. I did get one or two reports on failing on login, which turned out to be caused by special characters like < or > in passwords. As a quick fix, an escaping logic has been added to escape the special characters in passwords.
After the vSphere Java API 5.0 beta was released, I got a very interesting bug that I think is worthwhile to share with the community. Note that I used the word “interesting.” It turned out to have no solution logically, but quite easy to work around and patch up. The workaround addresses only particular issue but does not prevent similar bugs from happening in the future.
Confused? Let’s take a quick look at the bug report:
Among all the new features vSphere API exposes, I think VIX integration is very important. All of sudden, the vSphere API gets a boost on manageability of guest OS, and you can do many more with single set of APIs.
English
Recent Comments