Enterprise Live

Spring boot applications are now ubiquitous. The usual way to build one is to create an uber jar. At the same time, Docker allows us to build self reliant containers which are unaffected by the underlying server architecture or neighboring applications or their dependencies. Spring boot applications can also run in docker containers.  However running an uber jar inside a container fails to satisfy an important goal. That of high speed build and deployment. An uber jar is a heavy weight entity. That will make docker image heavy and slow to build. Here's a step by step solution, which leverages docker layer caching feature for faster builds with all spring boot goodness. We will use Maven to build a deployment structure for our docker image that allows fast deployments. Step 1: Create a spring boot application with only the SpringBootApplication and Configuration classes, such as one for REST configuration package scanning, one for JPA etc. Most often this wil...

Today someone asked me, how would Spring behave with respect to object instantiation if a Prototype bean was injected into a Singleton. This took me by surprise and the reaction was "Why in the world would we even do that?". Do we ever have instance level objects in Singletons, that might be prone to change, as that is what prototype beans would be for? No we do not, then why would we do that in Spring. The very intent of Singleton is to embody the logic of our application code, that has no state. It makes sense for Prototype beans, to have Singleton beans injected in them, for doing work. But the other way round, not so much. However, I went through the spring documentation and to my surprise there was a section(3.5.3) dedicated to Prototype beans injected into Singleton beans. And as expected, though it does not fail, such a dependency injection just results in a fixed instance of the Prototype bean to be injected into the Singleton. That instance does not change th...

SolrCloud is designed to provide a highly available, fault tolerant environment for distributing your indexed content and query requests across multiple servers. So what if we already have a standalone SOLR setup running on a single server and fulfilling ou search needs. As data grows or search traffic increases, vertically scaling that one single server is neither efficient nor cost effective. The answer comes as SOLR cloud and this document aims at providing an effective solution to migrating from standalone SOLR to a cluster with minimum effort. Step 1: Identify and setup SOLR and Zookeeper on required set of servers. Step 2: Start SOLR in cloud mode with the available Zookeeper configuration. Step 3: Rebuilding the cores. An efficient way to build the cores is to reuse our existing standalone SOLR setup.We can simply copy the existing SOLR core to the {solr.installation}/server/solr directory to start with. Copies of this SOLR core can be placed on all SOLR installati...

E xceptions happen!!! Rules are to be followed, too. Time and again, Java developers are told the golden rule to catch specific exceptions and not to catch the generic Exception. The thought process behind that is, applications should not catch runtime exceptions. This is apt as runtime exceptions are an indicator of "bugs" in the code. However, blindly following rules, as always, can have unexpected consequences. If you are developing services that are to be exposed over the wire, it is always a good idea to break this rule and "catch that Exception". Instead, follow the below principles: Service methods should implement a generic Exception block, along with catching declared exceptions, thrown from inner layers of the code.  If needed, the service can throw another exception back to the client. What's important is that we create a new Exception instance to be thrown, along with relevant message for the client. The service can log stacktrace for the E...