Saturday, January 11, 2014

Bumping up to jdk8 and JEE 7

I bumped up littleware's build to pull in JEE7 jars, and also went ahead and setup a jdk8 pre-release runtime, and so far everything works great.

I discovered a while ago when I bumped up to JEE6 that the Java EE dependencies are a little weird. The published JEE jar files are just intended for use at compile time, and only include the EE API definitions - no implementation. The idea is that a user builds his code against the API jars, and deploys to a JEE container that implements the APIs. If a developer instead deploys to an embedded environment like jetty or my fishRunner or just a standalone app that does something like using hybernate for JPA, then it's up to the developer to pull in the necessary implementation jars at runtime.

Tuesday, January 07, 2014

HTTP CORS Access-Control-Allow-Methods

I spent a few frustrating hours last week trying to figure out why PUT requests to a littleware web service I'm developing failed with an "unauthorized" HTTP 403 error code. I was thrown off for a while, because I assumed there was an error in the authentication and authorization filter protecting the web service, but that code worked fine for GET and POST requests, and the PUT requests didn't even appear in the server logs.

Anyway - long story short - I finally realized that the CORS filter protecting the web service was denying PUT requests by default. Fortunately, the open-source filter I'm using makes it easy to add PUT requests to the 'Access-Control-Allow-Methods' HTTP header in the pre-flight response.

So happy ending - the code works, and on to the next problem. This kind of bug is so frustrating though - when I do something a little out of the ordinary (HTTP PUT) that breaks some little part of a system that I've completely forgotten about, because it always works fine, and time is lost tracking down some configuration change rather than fixing logic bugs in code. C'est la vie!