Codelooru

In a web application, it is very important to handle errors. Proper error handling would protect the application from several vulnerabilities, including Security Misconfiguration . In this post, you will see how you can handle exceptions that arise out of a Spring MVC based application.

It is often required to run some custom code on initialization of a Spring bean. e.g. to check for mandatory properties or establish initial connections. Spring provides a few constructs to initialize the beans after they are injected with the properties.

Most common injection mechanisms used in Spring are Constructor and Property injections. In both the mechanisms, the injection happens only once during the initialization of the Bean. They also require a concrete method defined, e.g., a constructor method for constructor injections and a setter method for property injection.

Custom namespaces in spring are a way to replace the complex bean definitions with a more user-friendly configuration. Spring itself provides several namespaces out of the box. e.g.

Localization enables applications to cater to users of different locations and languages. Spring, as usual, has support for this aspect as well. Before jumping into what Spring has to offer, let's explore what we get from Java itself.

Spring boot , by default, enables you to create standalone applications through simple, minimal configurations. And due to its self-contained nature, it naturally enables building microservices. Spring starters are poms (if using maven) that

In the Spring Cache series so far ( Part1 , Part2 , Part3 , Part4 ), we have seen examples where the data is getting added to the cache through the use of @Cacheable and @CachePut . But, what about removing data from cache? Consider a call to delete the record from Service or DB, in which case, we would also want to delete that record from the cache.

Caching is an extremely important aspect of applications that care about lower latencies. There are a multitude of rules one has to adhere to while setting up a cache, in order to optimize the performance; but not overdo it. We will not get into those details in this post. Our focus would be on what Spring provides to enable caching in your applications.

JDBC queries by default do not have any timeout, which means that a query can block the thread for an unlimited amount time; of course, depending upon the DB load and the cost of the query. It is a good practice to timeout these queries if they can take longer than a certain amount of time.

The most common approach followed for overriding a spring bean is to define a new bean, with the same id as the original bean, in a separate XML file. During context initialization, Spring would register the last bean found for the id, and use it for all the injections. I dislike this approach for two reasons.

Caching resources on the browser is crucial to minimize unnecessary trips to the server and reduce the load on it. This works well for data that is static. But, there are cases where the data changes every once in a while (although less frequently), and you would want the browser to get the latest data without waiting for the cached data to expire. e.g., consider a scenario where a new version of the application is deployed with changes to CSS and javascript, and you want the user to experience these changes without forcing them to refresh their cache manually. One option you might consider is to make these resources non-cacheable and compromise the page performance a bit. Entity tags ( or ETags for short) help you cache such resources, without the performance compromise.

In one of my projects, I had an abstract controller class that simulated the form controller of Spring 1.2 for session forms. Annotations do not accept dynamic parameters. They have to be static. So, in the class, the command object name had to be a constant.

The annotations based MVC was introduced to the framework in Spring 2.5. This model enables the developer to reuse any POJO as a controller and is very flexible with the handler signatures. The old controller hierarchy is deprecated as of Spring 3.0. It would be removed completely from the distribution in one of the future releases.