cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wilder Rodrigues <>
Subject Re: [DISCUSS] Moving to Java 8
Date Thu, 23 Apr 2015 08:17:34 GMT
Hi Marcus,

I like the annotation idea, but reflection is trick because it hides some information about
the code.

Please, have a look at the CitrixResourceBase after the refactor I did. It became quite smaller
and test coverage was improved.


The same patter is being about to Libvirt stuff. The coverage on the KVM hypervisor plugin
already went from 4 to 10.5% after refactoring 6 commands


On 22 Apr 2015, at 23:06, Marcus <<>>

Kind of a tangent, but I'd actually like to see some work done to
clean up LibvirtComputing resource. One model I've prototyped that
seems to work is to create an annotation, such as
'KVMCommandExecutor', with a 'handles' property. With this annotation,
you implement a class that handles, e.g. StartCommand, etc. Then in
LibvirtComputingResource, the 'configure' method fetches all of these
executors via reflection and stores them in an object. Then, instead
of having all of the 'instanceof' lines in LibvirtComputingResource,
the executeRequest method fetches the executor that handles the
incoming command and runs it.

I think this would break up LibvirtComputingResource into smaller,
more testable and manageable chunks, and force things like config and
utility methods to move to a more sane location, as well. As a bonus,
this model makes things pluggable. Someone could ship KVM plugin code
containing standalone command executors that are discovered at runtime
for things they need to run at the hypervisor level.

On Tue, Apr 21, 2015 at 6:27 AM, Wilder Rodrigues
<<>> wrote:
Hi all,

Yesterday I started working on the LibvirtComputingResource class in order to apply the same
patterns I used in the CitrixResourceBase + add more unit tests to it After 10 hours of work
I got a bit stuck with the 1st test, which would cover the refactored LibvirtStopCommandWrapper.
Why did I get stuck? The class used a few static methods that call native libraries, which
I would like to mock. However, when writing the tests I faced problems with the current Mockito/PowerMock
we are using: they are simply not enough for the task.

What did I do then? I added a dependency to EasyMock and PowerMock-EasyMock API. It worked
almost fine, but I had to add a “-noverify” to both my Eclipse Runtime configuration and
also to the cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not nice, but was my
first attempt of getting it to work. After trying to first full build I faced more problems
related to ClassDefNotFoundExpcetion which were complaining about Mockito classes. I then
found out that adding the PowerMockRunner to all the tests classes was going to be a heavy
burden and would also mess up future changes (e.g. the -noverify flag was removed from Java
8, thus adding it now would be a problem soon).

Now that the first 2 paragraphs explain a bit about the problem, let’s get to the solution:
Java 8

The VerifyError that I was getting was due to the use of the latest EasyMock  release (3.3.1).
I tried to downgrade it to 3.1/3.2 but it also did not work. My decision: do not refactor
if the proper tests cannot be added. This left me with one action: migrate to Java 8.

There were mentions about Java 8 in february[1] and now I will put some energy in making it

What is your opinion on it?

Thanks in advance.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message