There is this neat plugin in Jenkins called Git Changelog which provides information about what was the git change that triggered the build. Recently I wanted to parse this change so I could send notification emails when certain things changed e.g: DB schemas.
My process for doing the same was:
Parse the changelog to populate certain environment variables
Based on values of said environment variables, trigger a conditional action
Send notification emails with relevant attachments.
Parsing the changelog:
* Get the current build:
* Get the gitlog changeset and entries within the changeset
* Parse entries to capture authors, comments and files changed
A lot of times we need to load entities into memory which contain a lot of nested relationships. Most of the time these nested relationships are lazy loaded which causes multiple queries being fired and causes performance issues. One solution to this to load the entity using fetches in hql but this can lead to another serious issue: cartesian product problem.
A better way to solve this is to leave the heavy lifting to the DB using a stored procedure and call the stored procedure from JPA as below:
Iterate through the results to get the object needed. If the stored procedure returns multiple sql results, hibernate maps it into multiple entity objects(one instance, multiple references). The API does not provide a way to restrict this as it does with hql queries.
Object[]resultArray=(Object[])results.get(0);//get the first result from the multiple duplicate resultsEntityentity=(Entity)resultArray[0];// get the main entity, since the result will contain an array of all the entities which are part of the result classes. Only references, not multiple instances.returnentity;
Logging is a critical part of any application. Without proper logging, teams resort to debugging in Production to diagnoze mysterious issues, Yikes!! I have been there and continue to live in that hell with legacy software which we all have to work with at some point.
Great, now everyone is on board with logging! Let’s fix this debugging in Production issue by adding logging in all our methods after every variable is set. Having all the information will fix everything right? -_____-. Pretty soon we realize that our excessive need for information and logging is bringing our application down. All that I/O is not cheap. Logging as with all of software development is something that has to be tweaked according to our needs as the code base grows. Too little or too much can have serious consequences.
Say we have tweaked our logging needs to log the exact amount of information with all the different levels configurable for different needs. Since we are working on a Java application, we use the widely used log4 framework. Everything goes great till we scale to process 10x the load we tested for. We scramble to make our code handle the load but we still run into mysterious bottlenecks. You got it, its logging again! Log4j-1-x logs synchronously, so as we process enormous loads, all that synchronous I/O eventually catches up and slows the application down. Logging is important but it is not critical enough to be the bottleneck. This brings us to Log4j2 and asynch loggers.
Here are the steps I followed to upgrade from log4j1 to log4j2:
Add the below entries to your pom. For log4j2 versions greater than 2.8, use disruptor version greater than 3.3:
Since log4j2 changed the logger package from org.apache.log4j.Logger to org.apache.log4j.logging.Logger, I wanted to write a wrapper around this so I did not have to change thousands of class files next time the package changed:
Create the below log4j2.xml to configure logging. I have mixed asynch and synch loggers here, but you can just set all loggers to asynch with the following system property:
Pass in JVM argument to provide path to the log4j2.xml file:
This was enough to get most of my logging done asynchronously but I still could not get hibernate logging to work. I had to do some additional configuration for the same:
Add the following slf4j dependency:
Pass in JVM argument for the jboss logging provider since Hibernate uses jboss logging:
After a long hiatus from Angular, started building a website with Angular 5 recently and was pleasantly surprised by the complete overhaul of the framework compared to older versions that I was familiar with(Angular 2):
Much easier object oriented support
Easy to use HTTP Client
Typescript which offers Dynamic Strong typing which makes it easier for compilers to spot erors but the strong typing is removed when translated to Javascript.
Getting Started:
Install NodeJs and npm
install angular CLI:
Create a new project:
Serve it:
Voila! Your Angular app is up and running.
Now let’s do something useful aka build a component(e.g: a login component):
This will generate a login component with the following files:
login.html
login.ts
login.css
login.spec
The structure is similar to earlier versions of Angular which used Javascript instead of Typescript.
To use this component, it has to be exported as an app module in app.module.ts:
Provide routing for the same in app.routing.module.ts:
Now to serve it on the app default webpage, edit app.component.html to contain:
That’s it. Easy as that. Now you can build slick interfaces using Angular and Angular Material. I will write more on this in subsequent posts.
Spring Boot comes with tools for building production ready microservices. One of the more important features Boot provides is Spring actuator.
Spring actuator provides information about your microservice. Once the service is up and running, the actuator endpoints can be accessed using:
By default only the info and health endpoints are enabled and exposed. The other endpoints are enabled but need to be exposed over http: