Adding CORS headers to your Java-based REST server responses is more tricky than it needs to be. There seems to be an oversight in Java EE’s filter handling, because when the container is configured with container managed authorization and a user that is not (yet) authenticated attempts to access a protected resource, the container intercepts that request and sends a 401 response. That response does not have CORS headers, but for some reason cannot be filtered. Neither with a Jax-Rs ContainerResponseFilter, not with a plain servlet filter. A container-specific solution seems to be the only way to get the job done.
I created an Undertow filter to get this job done easily for JBoss Undertow based EE servers. These include JBoss AS/EAP, Wildfly and Wildfly Swarm. The Github project, which includes installation instructions, can be found here:
I am currently in the process of publishing this project to Maven Central. Update will follow soon!
Problem / Bug:
For the last one and a half day I have been investigating a very curious problem. On one Windows XP machine here on our company network (my machine) the following line of code fails without any exceptions thrown:
The test.txt file is there. It opens normally when I double click it. Furthermore I can open it from Java using the (platform specific) Runtime API code:
Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler C:\\test.txt");
Also, if I invite some other user to log on to my machine and run the test application, it does work for him. I have created a new (local) account and for that account it did work. If i log onto some other machine with my network account and run the test application there, it works normally. Only on this specific machine with this specific account does the problem occur.
ASCII is dead! Long live Unicode!
You may not yet be convinced that you should abandon all legacy encodings used to encode text in all the different languages used around the world and switch to Unicode instead. If so, please first read this excellent article from Joel on Software to explain to you why. Don’t worry, I’ll be waiting here patiently for you to come back and read how to achieve the transition in your Eclipse Java projects.
Joel on software: Unicode and Character sets
Changing to Unicode? Yes, we can!
When first reading about Unicode, codepoints, character sets, character encodings and byte order marks, you might feel overwhelmed and start wondering whether this thing is even worth your while and how difficult it will be for you to convert your projects to use it. Are you really going to sell your software in Asia? Maybe you can do without it after all?
Don’t be worried. In fact, you can immediately forget about almost everything you read, especially when you work in Java, which is already using Unicode internally. It is not that difficult at all. I will go one step further and proclaim that the hardest thing about Unicode is not Unicode itself, but all the legacy encodings used in other software and files creeping into your project and breaking things. Stick to Unicode everywhere and you won’t have any problems with character encodings ever again. Promised!