Now with GitHub!
I now have a GitHub account and have decided to move my lengthier code examples over from DropBox files to GitHub Gist. You can find the links in the updated posts.
I ran into an issue where I was attempting to load properties for a Spring 3.0 web application in both the application context configuration and the web application configuration.The configuration was initially defined as follows:
Both the application context and the web context referenced the same ‘payment.proxy.X’ placeholders, however, only the placeholders in the application context resolved (ENV_CODE is resolved from the System properties). I found the following quote from Jürgen Höller, one of the founder of Spring, on the spring-dev list from a long time back:
PropertyPlaceholderConfigurer is an implementation of the
BeanFactoryPostProcessor interface: This interface and its sibling
BeanPostProcessor just apply to the BeanFactory that defines them, that is,
to the application context that defines them.If you combine multiple config files into a single contextConfigLocation, a
PropertyPlaceholderConfigurer defined in any of the files will apply to all
of the files, because they are loaded into a single application context.However, a DispatcherServlet has its own application context, just using the
root web application context as parent. Therefore, it needs to define its
own BeanFactoryPostProcessors and/or BeanPostProcessors, in this case its
own PropertyPlaceholderConfigurer.I believe that this is the better general solution: Each application context
might want to resolve its placeholders against its own properties files,
where applying PropertyPlaceholderConfigurer from parent contexts would
interfere.
I then defined the same PropertyPlaceholderConfigurer in both the application context and the web context and the issue resolved.
Wait, where’s my PDF?
I was recently working on a project where we needed to stream and render PDF documents from a Java servlet. Sounds easy and straight-forward, right? When initially developed, all browsers were rendering in the development environment (non-SSL). Here is the code snippet for how we were initially rendering the PDFs:
Standard Headers
private void setHttpResponseHeaders(HttpServletRequest _request, HttpServletResponse _response, int _contentLength) {
_response.setContentType("application/pdf");
_response.setContentLength(_contentLength);
_response.setHeader("Cache-Control", "no-cache");
_response.addHeader("Cache-Control", "no-store");
_response.addHeader("Cache-Control", "private");
_response.addHeader("Cache-Control", "must-revalidate");
_response.addHeader("Cache-Control", "maxage=1");
_response.setHeader("Pragma", "no-cache");
_response.addHeader("Pragma", "private");
_response.setHeader("Content-Disposition", "inline; filename=form.pdf");
}
Once we deployed to our test environment (SSL), we started to run into issues with Internet Explorer failing to render the documents. Apparently, this is a common issue. One of my co-workers originally tackled the issue by adding the “Accept-Ranges” header and the issue with IE was resolved. However, Firefox started to have issues over SSL with an error “File does not begin with %PDF-”. After much head-scratching over issues with different browsers and their behavior via SSL and non-SSL connections, the following is the final code that seems to solve the issue for most browsers:
Final
private void setHttpResponseHeaders(HttpServletRequest _request, HttpServletResponse _response, int _contentLength) {
_response.setContentType("application/pdf");
_response.setContentLength(_contentLength);
_response.setHeader("Cache-Control", "no-cache");
_response.addHeader("Cache-Control", "no-store");
_response.addHeader("Cache-Control", "private");
_response.addHeader("Cache-Control", "must-revalidate");
_response.addHeader("Cache-Control", "maxage=1");
_response.setHeader("Pragma", "no-cache");
_response.addHeader("Pragma", "private");
// only add the "accept-ranges" header if the "user-agent" header indicates Internet Explorer
String userAgent = _request.getHeader("User-Agent");
if (userAgent != null && userAgent.indexOf("MSIE") > -1) {
_response.setHeader("Accept-Ranges", "bytes");
}
_response.setHeader("Content-Disposition", "inline; filename=form.pdf");
}
The following is a matrix of our findings:
| Browser | SSL | non-SSL |
|---|---|---|
| Internet Explorer | requires “Accept-Ranges” header | standard headers |
| Firefox | forbids “Accept-Ranges” header | standard headers |
| Google Chrome | forbids “Accept-Ranges” header | standard headers |
| Safari PC | standard headers | standard headers |
Posting Blog Updates via Ping.fm
I was looking for a way to publish my blog updates out to all of my social networks all at the same time. WordPress.com offers the Publicize option inherently, but it only works with Twitter, Facebook and Yahoo. I have used Ping.fm for a couple of years to manage all of my updates to Twitter, Facebook, etc. Now I see that they also support posting via an RSS feed. Hopefully this works out well, as it will solve the social network updating for my blog.
Quicksort in Java
I was talking with one of my co-workers the other day about things that we had learned in our classes at our respective universities. I started thinking back to the classes I took at my alma mater for Data Structures and Software Engineering. I remember always being intrigued by the different sorting algorithms. On a separate note, I had read some rumors a while back that Java was replacing all sorting with Timsort as of Java 7. After taking a look at the API docs, however, I am glad to see that Quicksort is still being used. I always liked Quicksort’s simple elegance and it is a good overall sorting algorithm for medium to large-sized lists.
I am not going to go into the theory behind Quicksort or talk about any Big-O notation stuff here, as that is found anywhere on the web. I am also not saying that this is the most efficient implementation of this algorithm because I know that it isn’t. One thing that would make this sort run faster is to switch to a different algorithm such as Insertion sort when the size of a sub list during a recursive call falls below a certain threshold, as Quicksort does not do well on smaller lists. In my tests, this algorithm was sorting an array of 10,000,000 random Integer objects consistently in just over 8 seconds.
The source code is available here.
I was working on a Maven build a while back and was trying to figure out how to pass a JVM argument to the Maven Surefire plugin. We needed this capability in order to tell the underlying framework to not attempt to perform a JNDI lookup for its datasource and instead to use a DriverManager. I came across this little gem and thought I would share.
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <argLine>-DSTANDALONE_DATASOURCE=true</argLine> </configuration> </plugin> </plugins> </build>
