use Long insead of Integer in class GlanceImage

[whaon]

fix issue: #875

[whaon]

@auhlig ,hi,I've submit serveral issues and a PR,please help me to check it,thanks

[auhlig]

Hey @whaon, @tongh-qtl,
Thanks for the work.
I'm wondering if this is actually causing problems as the API specifically mentions integer for the properties you're referring to: http://developer.openstack.org/api-ref/image/v2/?expanded=show-image-details-detail#show-image-details

[whaon]

yes,it is definitely can cause a problem,consider the introduction of the field size:

size    body    integer The size of the image data, in bytes. The value might be null (JSON null data type).

the unit is in bytes,so the value may be two long
our system get a problem yesterday,so I think it is a potential problem to others
I think the integer in the doc is just indicate that this field is a nonnegative number,but the size may be huge,and it is not the concept of Interger in Java,thank you!
Long is always right but Integer not!

[auhlig]

I don't have a strong opinion here. Besides my previous comment - maybe I misinterpreted integer in the docs - I would be fine with this change. What do you think @vinodborole?

[vinodborole]

same thought @auhlig I am not sure, what do you think @gondor ?

[whaon]

the unit is in bytes

/**
     * A constant holding the maximum value an {@code int} can
     * have, 2<sup>31</sup>-1.
     */
    public static final int   MAX_VALUE = 0x7fffffff;

as above,the Integer.MAX_VALUE is 2147483647
2147483647bytes / 1024 / 1024 /1024 = 1.999999999068677425384521484375G
so the size of an Image can be as large as 2GB
but in actural,many Image can be more than 2GB

[vinodborole]

@whaon the change is valid no doubt about that. Will need a final confirmation from @gondor on this as this will not be backward compatible, people using the older version will have an impact on their exiting code when they port to new version.

[whaon]

@vinodborole It's OK

[gondor]

@vinodborole @auhlig Should we consider cutting a new release first (soon) before this merge since there is a lot of changes already in the release. Then we could have a smaller quicker follow on release with a few fixes and changes. It would be easier to see the breaking changes this way. Thoughts?

[auhlig]

@gondor Since murano service in os4j is unfortunately not making progress I guess it's the right time. Would leave current PRs open until after the release. So +1 for os4j 3.0.3

[whaon]

@auhlig @vinodborole @gondor
hi,may I close this PR and reopen it after the release 3.0.3,because there are another two issues need be fixed: #878 #877

[vinodborole]

@gondor I completely agree!

[whaon]

close temporarily

[whaon]

how about this issue now?Guys

[vinodborole]

@whaon will you be able to take this now?

[vinodborole]

reference to #875

@auhlig can you please review this pull request?

[auhlig]

Good to merge from my side 👍