We have been discussing going to a more serverless architecture at work and so I decided that I should do some research to see where that stuff is now. When I was at Choose we used AWS Lambda to implement the backend of an abandoned shopping cart service. We would then use that data to drive an email campaign to encourage the users to come back and finish purchasing an energy plan. It had a huge effect in driving conversion rates and we were able to implement the service in about 25 lines of vanilla java code. I opted not to use Spring as I judged the startup times to be too slow for it to be worth it. To manage libraries we used the maven shade plugin in our build process to build a fat jar.

I have an update on my slowdown issues on Sierra. It appears the real problem lies in the AWS Java SDK. After talking to the spring boot people via github they were able to narrow it down to an Amazon issue. I opened an issue on github with Amazon and they responded that the version of the SDK that ships in the current spring cloud has this issue in it, and it has been fixed in a newer version of the SDK. One of the big value propositions of Spring Boot to me and the release train concept of Spring Cloud or Spring Data is that it is a collection of dependencies that have all been tested together, which lowers my risk of using them together. So I opened a request with Spring Cloud AWS to upgrade their SDK. Unfortunately they don’t seem very timely in responding to issues as I notice it looks like there are no responses on any of the issues raised in the last 2 weeks.

Recently one of my friends was working on a Spring Boot project and he was having trouble finding an example of how to configure user login for his site with Spring Boot using JPA. I had mentioned that there is some mention of configuring security in Greg Turnquist’s book Learning Spring Boot. He had just purchased Spring Boot in Action and I don’t think he was rushing to grab another book, but he hadn’t been able to find a good online tutorial.

I am currently working on a project to move a bunch of data from SQL to Cassandra as the datastore. We have created a Cassandra Framework that looks very similar to the Spring Data JPA Framework that we use for SQL. Our Cassandra Framework we annotate data with @CassandraEntity and @CassandraRepository instead of @Entity and @Repository. For a time the data will live in both the SQL database as well as the Cassandra Cluster at the same time before we drop the SQL table. This will allow us to write to both tables and gradually switch over to the new cluster without as much risk if the cluster falls over.

I am a big fan of the work Oliver Gierke has done in Spring Data. It is a framework I use daily at work and it really is amazing. A while back Greg Turnquist had posted something on Twitter against field injection. So I asked what was wrong with field injection and he pointed me to this post that Oliver had written about it.

This post is going to be my attempt to argue against Oliver’s position on the subject. It may wind up an epic failure, but if nothing else I figured it would help me think through my thoughts and assumptions on the issue and see if I can make an argument in favor of it. First head over to Oliver’s post on the topic and read it before you continue on.

One of the most interesting Spring Boot features to me is the Spring Boot Actuator. I just love the concept of having all these restful endpoints to get useful operational data right out of the box. One issue I have had is that I don’t actually know all the endpoints just a few that I have used here and there. Today I saw a link to the Complete Guide for Spring Boot Actuator which is a pretty amazing post that covers everything and anything that you would want to know. The purpose of this post is just so I can go back and find this data later. If you are playing around with Actuators go and check out this post.

I am on a new project at work that looks to be very interesting. I am redesigning our Cassandra layer. Currently we have a beautifully done layer that was designed and implemented by our former architect. It ends up making Cassandra look just like a JPA entity and we have Cassandra Repositories that look just like Spring Data JPA Repositories. After this was in place we discovered the Spring Data Cassandra project. We went to the talk on Spring Data Cassandra and it turns out they had implemented pretty much the system that our architect implemented.

Last Monday I got into the office and I decided that is it, I am going to get our app upgraded to Spring 4.1. I had been working on this off and on for like 9 months, updating dependencies in the pom, doing some testing, wash, rinse, repeat…

As I had mentioned in a previous posts one of the first issues I had was the new aspect j running the hibernate metamodel generator and dumping a bunch of generated class in the root level directory of wherever maven was running. I had opened a Jira against the aspectj-maven-plugin. There was even a user who contributed a patch for the issue, and the developer promised to look at it in January but months went by with no effort to resolve the issue. Now CodeHaus is shutdown and the active projects have moved to MojoHaus. As of yet the aspectj-maven-plugin hasn’t been moved so more and more it looks like my decision to download the code from their SVN repository and fork it on github was correct.

I was checking the Spring Blog today to see what was new after taking much of the week off. I came upon the following entry. Of course I was very interested as Spring Security 4.0 has been hyped for a few months now so I figured I would check out the migration guide from 3.2 to see what will be involved for us to upgrade. I found this is the new feature section. They have added a feature which will now automatically prepend ROLE_ to any roles you use in Spring security if your role doesn’t start with that. So if you have a role called ROLE_USER for a standard user you can now just say @PreAuthorize(“hasRole(‘USER’)”).

I saw this come across the Spring blog this week. They are going to be doing a webinar for JHipster. As I mentioned in a previous post I am very interested in JHipster as it combines 2 things I am interested in learning Spring Boot and Angular. If you are interested in checking it out sign up here.

Also as a completely unrelated side note, why doesn’t projects.spring.io support HTTPS? This is 2015 and all sites should really support secure access.

My coworker discovered that the new version of AspectJ already has the flags built in to turn off the annotation processing. If we can do that we can continue using the Maven Processor Plugin to generate the Hibernate Metamodel data and not have to abandon this. The problem at this point is the AspectJ Maven plugin doesn’t support passing those flags along to AspectJ. So the next step is to get a patch in to that plugin and hopefully we can make the jump to Spring 4.1 at the start of the new year. After that I am going to focus on updating our container so we can finally make the move to Java 8 at work.

I was fortunate enough to attend SpringOne this year and I attended a talk by Venkat Subramaniam on Java 8. I have to say before attending this talk I have always been sort of meh on the functional features brought into the language, but this really got me excited about them. This is the first talk on functional programming that I have ever heard that wasn’t boring, but really engaged the listeners. I strongly recommend people check it out:

For a while now I have been avoiding upgrading the maven java compiler plugin. We are running 2.5.1 at work. The problem is, in the 3.x version, they seemed to have rewritten it, and it doesn’t want to play nice with the maven-processor-plugin that we used to run the hibernate meta model generator. So far it was like cool, I just won’t upgrade to the new version.

Then AspectJ came out with 1.8.2 and the new AspectJ compiler plugin which also seems to be built like the new compiler plugin. At this point I was like well then I might as well update both since Spring 4.1 wants at least AspectJ 1.8.2. But I still have the whole thing fall apart at that meta model step. I found a flag for the maven compiler about forceJavacCompilerUse but even that didn’t solve the problem for me. A coworker said basically AspectJ seems to be doing what we were using the maven-processor-plugin for and generating the meta models for the entities, so he disabled that plugin. However for some reason instead of dumping the generated files in the target directory it is putting them in whatever directory you are in for the build and we can’t seem to find a way to get it to drop them in the target folder.

I was messing around with some of the settings in the Java 8 VM. I have been playing around with Spring Boot lately. So I have a minimal webapp in Spring boot, that has a couple of entities, and services and controllers. I have it configured to run as a standalone jar with an embedded tomcat 8 server. When I do a java -server -jar myapp.jar Spring boot launches my app and when it finishes loading the java process is sitting at 870,160K of memory.

Earlier this year Spring Framework 4.1 was released. I was excited to try out the new features in our project at work and having previously upgraded us from Spring 3.1 to Spring 3.2 and from Spring 3.2 to Spring 4.0 I was expecting this to be another routine Spring update, but alas that was not to be.

One of the first things I do when looking to do a major version upgrade is to check all the dependency versions for the libraries to make sure all of our libraries are new enough to do the upgrade. In this case I discovered that Spring 4.1 requires Jackson 2.x and we were running Jackson 1.9.x.