Hi,
I'd like some thoughts how to handle an issue I have with filenames in shrinkwrap produced war files.
I use shrinkwrap to create a war file like this:
WebArchive war = ShrinkWrap.createFromZipFile(WebArchive.class, new File("../myproject/target/myproject.war"))
.addAsResource(new File("../mypackage-itests/src/test/resources/SomeTestResources"))
.addAsLibrary(new File("../mypackage-itests/target/mypackage-testutils.jar"), new BasicPath("mypackage-testutils.jar"));
I then use this with Arquillian to run some integration tests. In one of the tests I refer to a resource in the produced war like this:
InputStream resource = getClass().getClassLoader().getResourceAsStream("SomeTestResources/prim\u00e4r.jpg");
There is an "ä" in the filename. The line above returns null on Amazon Linux, but works fine on Mac. I've figured out that the unicode codepoints created in the war zip entries depend on the operating system.
On Mac Shrinkwrap produces a war file where the zip entry contains a file called prim\u00e4r.jpg where ä is encoded as codepoint 0xe4. On Amazon Linux Shrinkwrap produces a war file where the zip entry containing ä has it encoded as composite characters (codepoint 0x61 followed by codepoint 0x308).
The fact that Shrinkwrap war creation depends on the underlying platform makes it a little unpredictable. Would you agree?
I successfully worked around this by implementing my own addAsResource() which uses java.text.Normalizer(filename, java.text.Normalizer.Form.NFC) and puts the normalized filename into the war zip entry. This way ä is always treated the same regardless of the operating system. This solution works for me, but as a good citizen I'd like to know if this is something that should be put into Shrinkwrap?
Thanks,
Tim
