Fix NuageVsp errors for build-master-slowbuild

[nlivens]

No description provided.

[nlivens]

@DaanHoogland, this PR contains the fixes for the build-master-slowbuild

[DaanHoogland]

thanks @nlivens lgtm but will run regression tests.

[fmaximus]

I think we should use StringUtils.getUtf8Bytes() instead, as we are using StringUtils.newStringUtf8(Base64.decodeBase64(cmsUserPassBase64)) on the other side (NuageVspResource:192)

Otherwise it would fail if StringUtils.getPreferredCharset() is different from UTF-8

[DaanHoogland]

@fmaximus preffered charset will be utf8 if it is available in the virtual machine (afaik always) otherwise it is the platform default

[DaanHoogland]

1092.test_network.results.txt
1092.test_vpc.results.txt

Note that the two errors test destoying the system VMs. These timeout but the system VMs come back after the timeout.

Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : EXCEPTION ===
ERROR
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : EXCEPTION ===
ERROR

LGTM

[nlivens]

@DaanHoogland, @fmaximus was right about the encoding. I rewrote that part so we're always using the same encoding :)

[DaanHoogland]

@nlivens @fmaximus I have to ask you to reconsider. if getPreffferedCharset() does not return UTF8 it is because it is not supported on the platform. how do you handle that situation?

[nlivens]

@DaanHoogland, how about the following piece of code then? In this case we are using the getPrefferedCharset()

    public static String encodePassword(String originalPassword) {
        byte[] passwordBytes = originalPassword.getBytes(StringUtils.getPreferredCharset());
        byte[] encodedPasswordBytes = Base64.encodeBase64(passwordBytes);
        return new String(encodedPasswordBytes, StringUtils.getPreferredCharset());
    }

    public static String decodePassword(String encodedPassword) {
        byte[] encodedPasswordBytes = encodedPassword.getBytes(StringUtils.getPreferredCharset());
        byte[] passwordBytes = Base64.decodeBase64(encodedPasswordBytes);
        return new String(passwordBytes, StringUtils.getPreferredCharset());
    }

[DaanHoogland]

@nlivens looks good, but I have some questions still

1. So why wouldn't you encorporate this in your getBytesUtf8() and newStringUtf8() methods?
2. How will the plugin behave when utf8 is not supported (not sure if it will ever occur but let's say running on the level frame OS)?

[nlivens]

@DaanHoogland

1. getBytesUtf8() and newStringUtf8() would no longer be used.
2. With this new code, we won't any longer be only dependent on UTF-8, but rather on the Charset returned by StringUtils.getPreferredCharset().

You can have a look at the newly pushed code :)

[DaanHoogland]

@nlivens .1 : my bad .2 remains but is not specific to this patch and even this plugin. LGTM I asked @remibergsma on slack to have a look as well.

[remibergsma]

LGTM, all integration tests pass.

[rafaelweingartner]

The code seems ok, but what about a PR description and test cases for those encode and decode methods that were created?

[nlivens]

@rafaelweingartner, I've added a test for those methods

[rafaelweingartner]

@nvlivens,
I would suggest you to write two test cases instead of one.
One test case to test the encode method and another to test the decode method.

[nlivens]

@rafaelweingartner, implemented the test cases as suggested

[rafaelweingartner]

The code LGTM now

[nlivens]

@DaanHoogland, @remibergsma, can this be merged in?