I was making a custom dashboard for Horizon the other day. In one of my views I was using tabs and in each tab I had a table that supported pagination. There was a problem where when I would go to tab 2 page 2 I would get an error about not being able to load data for tab 1. It was pretty clear to me this was an issue with pagination. I tried various things to work around the bug I had but nothing seemed to work. I took the advice a good friend of mine always gives me when I get stuck “Dont trust the docs, they lie. Go read the code its the only source of truth.” so I did just that. I quickly found the answer to my problem. Inside the tables base class I found the class had a variable for pagination that defaulted to “marker” and in the comments for that particular variable it said “When using multiple tables in a single view this will need to be changed to differentiate between the tables.”. That was simple enough, like always I wish I had gone to read the code sooner. Now to implement the fix and get rid of my bug all I had to do was go to my table classes and add the following bits of code:
name = tables.Column("name", verbose_name=_("Name"),
properties = tables.Column(images_md_to_str, verbose_name=_("Metadata"))
name = "images"
verbose_name = _("Images")
table_actions = (MetadataFilterAction, CreateImage, DeleteImage, )
launch_actions = ()
if getattr(settings, 'LAUNCH_INSTANCE_LEGACY_ENABLED', False):
launch_actions = (LaunchImage,) + launch_actions
if getattr(settings, 'LAUNCH_INSTANCE_NG_ENABLED', True):
launch_actions = (LaunchImageNG,) + launch_actions
row_actions = launch_actions + (CreateVolumeFromImage,
# Define the following 2 variables to fix pagination issues
pagination_param = 'image_marker'
prev_pagination_param = 'prev_image_marker'
Defining the pagination_param & prev_pagination_param and using a unique name for each class is all it takes to fix that issue. I hope this info comes in handy for someone out there. I spent more time on trying to fix this than Id care to admit 😉
Today I am proud to announce that I have released yavijava-6.0.01 This was a huge task for me to complete. While doing it I realized if I wanted to get these done in a timely manor going forward I would need some automated tool to help get the work done. I spent a couple of days and built a tool called yavijava_generator. It is a tool written in Groovy that will parse the HTML docs provided by VMWare and generate the new classes and update old ones with new properties speeding up the process to deliver new versions by 100’s of times. This release today includes some bug fixes as well. A security flaw was pointed out to on the vijava forums about vijava changing the global security context when you passed the ignoreInvalidSSL flag. I have addressed that in this release. I have also included a massive amount of logging. If you want to see ALL the SOAP payloads being sent to the server, and the payloads the server is sending you all you have to do is enable trace level logging on com.vmware Please be aware this WILL INCLUDE PASSWORDS in plain text in your log files. I have also made a lot of progress in testing coverage. Please upgrade to this version and et me know if you run into any problems.
Do you currently use vijava? Have you noticed how the forums are kind of dead (meaning lots of questions, but no one from the project answering those questions), and there have not been any more community releases since 2013 or so ending with 5.5 beta? I noticed these things, and so I did something about it. I forked the project and started maintaing it. I have done a lot of work on the project. I have added logging using log4j. I have added the ability to RESET VCENTER ALARMS FROM RED TO GREEN. I have fixed several bugs including a bug where every single exception was being wrapped in a RemoteException causing you to have to check the exception.getCause() to find the underlying exception instead of being able to catch normal vCenter exceptions. I have refactored the code allowing you the user to provide your own HTTP clients should you need to, and even added a great deal of tests to the code (this is an ongoing work in process). I also converted the project to use gradle. This makes building the project a snap.. But wait theres more!! I fixed a bug in the InventoryNavigator which made the 5.5 release not work properly with vSphere 6.0.. speaking of 6.0 I have been hard at work adding support for vSphere 6.0 and Im happy to announce the beta release is done and available right now! With the help of people from the community work is being done RIGHT NOW to add SPBM support to yavijava as well!! One of the best parts about all of this is that I have maintained compatibility with vijava so switching to yavijava is painless for you the user!
So.. How do you switch? Switching is simple. If you have a project using maven you can simply update your pom, or gradle, or what ever to point at the yavijava repo. As of this blog post the current stable release is 5.5.11. If you are just grabbing the jar file to include in your project some other way thats fine too. Please be aware that I did introduce new dependencies, so if you are manually downloading jar files (you should consider stopping that and moving to gradle its super easy to do) be sure to check the build file for the latest requirements.
If you do run into any issues please report those issues on the GitHub issue tracker. When you submit an issue please consider reading over this basic guide I created. If you do not have a bug but just have a question, you are welcome and encouraged to open an issue and ask your question there, or join the web chat and ask there, just be sure if you cant wait around for an answer to open a GitHub issue.
I really look forward to growing the community and bringing it new life. Please help me spread the word about yavijava, and welcome to the community!
If you didn’t already know I created a fork of vijava called yavijava. It is quickly becoming a pretty popular alternative to using vijava due to the features I have implemented like fixing the InventoryNavigator in the current production release found in public maven central. That fix makes 5.5.10 and newer releases have a functional InventoryNavigator on vSphere 6.0. Ive also added other features like logging using log4j, and the ability to reset Alarms from red to green. Ive also been hard at work adding full support for vSphere 6. With all of these things going on I also decided the project was getting so popular it was time to move it to its own GitHub Org.
A lot of these things have caused a great deal of confusion for end users of the library. Questions like:
Which version of yavijava should I be using?
Im using vSphere 6. Shouldnt I be using the vsphere_6 branch of yavijava?!?
Where do I report issues Im having with yavijava?
Is there a place for chat support?
I plan to address these questions in this post. Ill start by answering the first question of Which version of yavijava should I use? The answer to that depends. Ill start by asking you a very important question:
Are you looking for the latest stable and supported version for use in production code?
If your answer to that question is YES! then you need to be using the latest version available in public maven.
Now for question number 2 Im using vSphere 6. Shouldnt I be using the vsphere_6 branch of yavijava?!? Let me ask you another question to help answer that for you:
Are you comfortable testing an ALPHA version of a library that is in no way ready for production use?
Are you a developer who is looking to help get vSphere 6 fully supported by submitting code to yavijava that implements new properties, DataObjects, or ManagedObjects so the new features added to vSphere 6 will work in yavijava?
Are you a tester who is wanting to help get vSphere 6 fully supported in yavijava by submitting detailed bug reports about things in vsphere_6 branch that have been implemented but are not working?
Unless you answered YES! to some or all of those questions DO NOT USE vsphere_6 BRANCH! Support for vSphere 6 in the vsphere_6 branch is NOT DONE. There is a lot of work left to do and pretty basic stuff will fail until the work is done.
Now for the next question: Where do I report issues Im having with yavijava? This one is pretty easy.
Are you testing new versions of vSphere with VIJAVA and finding problems with the InventoryNavigator? Missing properties, and missing inventory are common complaints when using VIJAVA and new versions of vSphere. Never fear though! YAVIJAVA is here to save the day!!
The InventoryNavigator is not a default part of the VI SOAP API and was added by the creator of VIJAVA. In that class he uses the PropertyCollectorUtil to create complex TraversalSpecs that can be used to traverse an inventory very quickly. VIJAVA has been around for a very long time and supports many versions of vSphere. To do that there are a couple of helper methods in the PropertyCollectorUtil that can be used to make traversal specs. One of them is meant for use on older vSphere systems (pre 4.0), and one of them is meant for use on version 4 and newer vSphere systems. In the InventoryNavigator there was a check being done against the string that contained the API version to try to decide which version of the TraversalSpec creator should be used. The problem with new versions of vSphere and any version of VIJAVA (as of March 8th 2015) is that VIJAVA has a conditional where it was looking specifically for version 4 or 5 in the version string to load the newer TraversalSpec method. I reworked that logic in the YAVIJAVA code base for now so if it finds any version >=4 it will load the newer TraversalSpec else it loads the old one. Give it a try on those newer vSphere versions and report any issues you may have in the GitHub issues. This rework was added to 5.5.10-DEVELOPMENT I plan to release 5.5.10 to public maven in April. To use the development version just check out the code from github and use gradle to build the jar with the following commands:
git clone https://github.com/yavijava/yavijava && cd yavijava && gradle build
This will build the jars for you. Take a look in build/libs/ for all the jar files.
Do you need to set some kind of Key, Value info up on a VirtualMachine in vCenter that you can access from the API? I thought with 5.5 and the addition of this that there was going to be some kind of actual Matadata fields added to the vSphere API, but it seems that still hasnt happened, as this is incomplete and missing any way to actually use it. The good news is that since 4.0 there has been a way to add key value pairs to the vm.config.extraConfig. The key has to be a String, and the Value can be an object. I have used this to store all kinds of stuff from Strings to JSON and XML payloads and even base64 encoded files. I wrote a sample for the pyVmomi-community-samples project that uses the vm.config.extraConfig to store some key value pairs. You can get it here until it gets accepted by the project and merged into master.
I recently added a patch to YAVIJAVA that allows you to reset an alarm status. William Lam has posted in the past about how to hack the perl sdk to add this functionality, so I thought it would be a good idea to add this functionality to YAVIJAVA. I have manually implemented this in Groovy and in python for pyVmomi so adding it to the primary library I use seemed logical. Im still doing a bit more re-work to YAVIJAVA but if you want to use that now you can check out a copy from GitHub and use the gradle build script to build a copy for your self.
Using this new functionality in YAVIJAVA from Groovy (which is how I do it) would look something like this:
ServiceInstance si = new ServiceInstance(new URL(""),"","", true)
Folder rootFolder = si.getRootFolder()
HostSystem hostSystem = rootFolder.getChildEntity().hostFolder.childEntity
AlarmState alarmState = hostSystem.triggeredAlarmState
Alarm foo = alarmState.alarm as Alarm
AlarmManager am = new AlarmManager(si.getServerConnection(), foo.getMOR())
am.setAlarmStatus(foo, hostSystem, "green")
I havent tested this yet so YMMV. Before I do the next official release of YAVIJAVA I will have tested it out and include a working sample.