Here's the stacktrace:
I was able to find the cause: http://docs.oracle.com/javase/7/docs/api/java/util/zip/ZipEntry.html#getSize() may return -1 when size of the entry is not known. For some reason, in my environment -1 is returned, despite the fact that EAR file in question is valid, and I can see entry sizes correctly reported when using unzip -l in console.
Luckily the issue is easy to fix by eliminating the intermediate buffer into which the manifest data were loaded in the existing implementation and pass the ZipInputStraem into Manifest constructor directly.
After applying the attached patch manifest rewriting proceeds correctly and application (and it's associated driver and datasource) are deployed successfuly.