Ivan Lagunov's Blog

This article is devoted to an upgrade of a common JSF Spring application. Time flies and there is already Java EE 7 platform out and widely used. It's sometimes said that Spring framework has become legacy with appearance of Java EE 6. But it's out of scope of this post. Here I'm going to provide notes about the minimal changes that I found required for the upgrade of the application from JSF 1.2 to 2.1, from JSTL 1.1.2 to 1.2, from Servlet 2.4 to 3.0, from Spring 3.1.3 to 4.0.5, from RichFaces 3.3.3 to 4.3.7. It must be mentioned that the latest final RichFaces release 4.3.7 depends on JSF 2.1, JSTL 1.2 and Servlet 3.0.1 that dictated those versions. This post should not be considered as comprehensive but rather showing how I did the upgrade. See the links for more details. Jetty & Tomcat. JSTL. JSF & Facelets. Servlet. Spring framework. RichFaces. Jetty & Tomcat First, I upgraded the application to run with the latest servlet container versio

Quite a while ago I had users complaining they could not use my application from another secure network zone. It appeared the root cause was in using Yahoo CDN for serving YUI resources while there was no internet access in that specific network zone. Also living behind a proxy, our regular users used to suffer from longer delays from time to time due to proxying. An obvious solution turned out to be using a locally served YUI. For this a combo loader is required if you care about efficiency on Production. Installation To start with, there are several alternative open-source tools that can be used for combo loading: Official PHP loader by Yahoo – is obsolete and is said not to work with any version over 3.3.0. CGI script combo – I cannot say much about it besides that it's 3 years old. Node.js combo handler – is kept updated and is the one that I decided to use. The Node.js combo handler is supplied with rather self-contained README file at github. Nevertheless, I&#

In this article I'm going to show a common use case of XML Catalogs . Their usage is not only recommended to avoid certain issues but can also drastically improve the performance. I'll start with explaining the issue that I've faced recently and will conclude with the resolution. Issue To start with, I've got the following exception: java.io.IOException: Server returned HTTP response code: 429 for URL: http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd The HTTP code 429 stands for "Too Many Requests" that can appear when: The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes Just to provide some context, I have an Apache Cocoon based application that does a lot of XSLT processing with Saxon . It appears that every time Saxon reads an xml document with a DTD reference, it tries to fetch the DTD source for validation. Obviously, if the processing rate is high enough and there is no caching, you can cre