Recap for 2016

End of year recap

It’s that time again. Time to reflect on my themes for the year and see how I did on them. This is an annual tradition of mine to see how I am doing in general. I find it is a useful accountability tool for myself to make sure I am not wasting too much time on unimportant things and am spending the time that I would like on personal development.

Theme 1 -Regular Blog Updates

This theme was an epic failure. I count 21 posts for the year. Less than half of last years posts. I could make a couple of excuses but it all comes down to the major changes in my life in 2016. It started in February with the birth of my 3rd child. The first 3 months of a new baby wipes you out mentally and physically so that already made things a challenge.

After that I made another major life change, I took a new position as a Principal Engineer at a startup company. This was a great change for me and I am really happy to be working on a new exciting project. Back in April I was working on a major architectural project at my previous company and all of a sudden 3 different recruiters hit me up with 3 interesting opportunities. Like most people in software development I see about 3 – 4 job inquiries per week from various recruiters. I would say 95% of these positions sound terrible, so it is pretty easy to dismiss them generally. I was in a very good position in my previous company so it is also easy to be selective about what you are willing to take. So to see 3 really good opportunities at the same time where the work sounds exciting, the companies sound interesting and the pay is very competitive is most unusual for me.

I started down the road with the first company, when the second recruiter contacted me. So I started talking with them and it is at this time I realized that the first company wasn’t going to be a culture fit for me. Their culture would require that I fly to Portland every 6 weeks to meet up with the other development team there and that was just too much travel when I have 3 young children. The morning that I was going to do my onsite interview with the second company a recruiter that I have talked with for about 8 or 9 years dropped the 3rd opportunity into my lap. Another startup position which had me interested. I arrived for my onsite interview at the second company and we spent some time discussing the type of Software Development that I enjoy doing as well as what I would like to do ideally with a software architecture. The interview went great and about 3 hours after I returned home from that interview I was contacted by my recruiter and he said they wanted to move forward with an offer. I was pretty excited by everyone I had met so I didn’t end up moving forward with the 3rd company as I had found what I was looking for.

Theme 2 – Read Lots of Books

As expected this fell off for the year compared to the previous year with all the new changes in my life. But I did really get back into it in the fall here and have read some good stuff. On the religious side I have been working on Last Testament by Pope Benedict XVI, and The Confessions by St Augustine. On the programming side I have been working on Functional Programming in Java by Venkat. I can’t recommend this book enough it is absolutely amazing. In Non Fiction I read Hillbilly Elegy by J.D. Vance. This book is also amazing to understand a part of the country that is often ignored. Anyone who was confused by the election results this year should really read this book as I think it lays out why middle America is so angry. Anyway that is a small selection of what I have read or am reading.

Theme 3 – Work Stuff

My third theme was some work stuff that I wanted to get done. That didn’t happen due to me changing jobs, but at my new company I have a new list of things that I want to get done for 2017.

Theme 4 – Swift

While I didn’t get around to Swift or iOS development this year I did spend some time in a different language. For the last 2 months we have been doing a lot of front end work at the office, so I have been learning angular.js and lodash. In the past I haven’t found JavaScript that interesting, but I have to say with using angular and lodash it is growing on me. Lodash is ridiculously powerful and I feel like the key to being productive in the JS world is to know this library. Angular brings a lot of patterns that remind me of Spring development which is also nice coming to it from my background.

Theme 5 – More work stuff

Again I didn’t hit this theme as I left my previous role before I got to this, but I did do something sort of similar. When I was interviewing for my current role I mentioned that I would like try doing a micro service architecture built around Spring Boot. I felt like this might make for more maintainable code long term. One week into my new job I was tasked with rolling out this architecture and designing and implementing the first micro service. We had 2 sprints to get it done. It took a big push, but we made it and it was a huge success. Later this summer we rolled out the second micro service. The other developers have been very happy with this architecture and it looks great from both a scale-able application standpoint and from a devops standpoint as Spring Boot is built with devops in mind which really makes it easy to roll out new services.  We will be beginning our 3rd Spring Boot app starting with the first sprint of 2017.

The other aspect of this theme which is relevant to my new role is there are certain aspects of our legacy app’s architecture that I would like to evolve and improve and I have already begun working on that. I am reworking the persistence layer to more heavily lean on Spring Data JPA and less raw Hibernate. I am also reworking the Controllers to use the latest Spring annotations like GetMapping and PostMapping as well as the way we wire the services with the goals of just making all new development on the older platform faster and more lightweight.

Theme 6 – Open Source Contributions

This was a failure. I did some reporting on issues so I at least tried to work through issues I saw, but with the new baby and new job I was far too short on free time and mental energy to dive into another code base and try to contribute to it.

Closing thoughts

If we just want to score this on what I hit it looks pretty bad. That being said I am really happy with my year. It has been a great year. As I said in the post laying out the theme, it doesn’t really matter to me whether I do these things what I care about is personal growth. That is part of the reason for themes and not concrete goals. And on the growth concept this has been a fantastic year. The year turned out completely differently than it started out and I am really happy with where I am. Over the next few days I will lay out the themes for 2017 for me.

MacOS Sierra massive slowdown in Java networking

I upgraded to MacOS Sierra, and have really been enjoying the shared clipboard. I haven’t really noticed any other new features that impact my day to day development, however I would advise Java developers to avoid it for the near future. I have searched and searched and I wasn’t coming up with any results. Then I found this blog post. This is definitely part of the problem. I made the host file changes and got a slight boost, but not enough to explain the whole thing.

First our original application is a monolithic Spring 4.2 app running in Tomcat. On my MacBook Pro it was taking 21-25 seconds to launch. After going to Sierra it started taking 75 seconds. Once I did the host file fix in the blog post above it started launching in 59 seconds. Still much worse than before.

Another Spring Boot micro service we have that does a lot of external api calls and also communicates through Amazon SQS would previously launch in 11 seconds on my laptop and now takes 141 seconds (150 prior to the fix outlined above). Even worse the messages to and from SQS and the third party API’s are painfully slow, sometimes taking 30 seconds or more to go through when previously they were almost instantaneous.

I am still searching for a fix for the issue, but it is practically unusable. I am debating if I am going to roll back to El Capitan, but at this point I would recommend people hold off on upgrading until there is a good understanding of what the slowdown is and how to fix it. Java itself when not hitting the network seems as fast as ever.

A Two Month Recap

It has been a crazy couple of months. Since I last posted I made a trip out to San Francisco to meet the rest of the team I work with (and had a great time). If you live in Texas there is no better time to visit San Francisco then at the end of July. It was a welcome break from the heat. I had a great time and realized when I was out there that I hadn’t been out there since 2005, so I was over due for a trip. I had forgotten how much I love that city it is a really fun place to hang out (though not a place I would really want to live).

We are also about to launch our second Spring Boot Microservice. This one I am really excited about it is even more ambitious than our first one and should provide huge value to the business. The interesting new technology we used in this one is Amazon’s SQS (Simple Queue Service). I am going to say off the bat that the documentation for Spring Cloud is kind of crap, so I spent a lot of time debugging the framework to figure out how to integrate this thing. But now that we have it working it seems to work great. It definitely is pretty light on features compared to something like RabbitMQ, but it seems to get the job done and the Spring Integration is great. I am hoping to put out a blog post on how to configure it as we got hung up a few places with it.

One of the nice things about going to SQS is it forced me to upgrade our Monolith to Spring 4.2 from 4.0 as the current Spring Cloud Brixton release train won’t run on Spring 4.0. I am hoping to roll out Java 8 there as well in the next couple of weeks so that we will be sitting on a fairly current framework on our oldest app and our Microservices running the latest and greatest of everything.

We already have 2 more microservices planned out, it is just a matter of figuring out how they will fit into the product roadmap. I think once we get that delivered we will have cut our monolith down quite a bit and I hope at that point it will be small enough for me to convert it over to boot and simplify it. As I see lot of opportunities to really get everything we are doing lean which should let us turn around features for the business even faster.

Anyway that is the latest update, hopefully I can carve out some time to work on a SQS configuration post. Until next time…

Spring Boot and Security using Spring Data JPA for authentication

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.

Today I was browsing Twitter and I came across exactly what my friend was looking for. Priyadarshini B wrote a great online tutorial on doing just that on her blog. The post was so great I wanted to share it. So head over there and check it out, you won’t be disappointed as it will walk you through the whole process.

Recap for 2015

At the start of the year I posted my Themes for 2015. I decided now is a good time to look at what I was thinking at the start of the year and see how my year turned out. I think it is sort of pointless to set out some ideas of things you want to accomplish if you never stop and assess what you actually did, so this is sort of an accountability post to myself to see how things played out for the year.

  • On the first idea of working on weekly updates. I didn’t accomplish that. On the other hand if we look at it from a post count standpoint I did average that, so I would call that a pretty successful year for my blog even if there were points that I went a whole month without putting some thoughts down.
  • The next theme was to do more reading. Overall I was pretty successful with this. I didn’t always meet the 10% of my kindle book a day, but I did actually read more books than the previous year. I would call that a success, I hope to keep the momentum going, but with another baby on the way this year, I will probably read fewer books this year. I find that when I am overtired I can’t read as it just puts me to sleep so depending on how soon my little one is sleeping will depend upon how much reading I end up doing.
  • The next thing on my list was spending more time doing stuff in Spring Boot. I did a little bit of work on the side playing with the framework. I am convinced that this is the only way to do development with Spring going forward, but migrating a very large legacy app in that direction is easier said that done. On the positive side though our organization did roll out a new microservice in spring boot this year, so we are beginning to bring it into production. The real key will be migrating the bulk of our code to the framework.
  • The next idea I had was to try to learn Angular and get more serious with that. I can say that did not come to pass. I did take Code School’s shaping up with Angular.js course, and I just recently noticed they have added the next level to the free plan. I may end up messing with that over the coming year, but I am not sure. I am sort of watching to see if I think people start moving over to Angular 2 or if the change in compatibility is going to hurt the popularity of the framework. Also I am hearing more buzz about react.js so that is always an option to look at as well. Either way 2015 was not a year of doing front end stuff for me.
  • For my architectural updates 2015 was a huge success. It started off slow with having issues aspectj-maven-plugin. I was forced to fork the project temporarily on github as the maintainer showed now interest in rolling a patch that someone contributed to solve the problem. Then codehaus shut down. After they moved the project into github one of the other maintainers rolled the fix in when I pointed out it was in the old Jira. So I was happy to be able to abandon my fork of the project and get back on the mainline branch. Then I ended up ripping the whole Hibernate Metamodel Generator out of the project anyway which probably wouldn’t have necessitated needing the aspectj plugin update, but that happened later in the year after we needed that upgrade. After getting the aspectj plugin situation resolved I was able to get us upgraded to Spring 4.1. Even better than that we closed the year running the 4.2 branch. So that was beyond what I was hoping to get done. JBoss finally released EAP 6.4 in April which is what I had been waiting on in order for us to upgrade to Java 8. We were able to get the container upgrade into production this fall. Then a few weeks later we switched our VM to Java 8 with that JBoss and ran successfully with that. Finally near the end of my work year in December I was able to switch our compiles to Java 8. So we are now at a point where we can use all the new lambdas and streams and I look forward to playing around with it in January.

All in all I was very happy with my year. I will spend some time in the near future to figure out my plan for 2016, I have some big ideas at work I want to deal with and I even have a few ideas for home projects to mess around with too. So here is to a great year that just ended and an even better one going forward.

Update

I was thinking I should probably have noted anything big that actually happened that I didn’t predict.

  • I got to learn a bunch more Cassandra since I reworked our whole Cassandra Data layer as part of a big project to hide some of the complexity of what we are doing from the rest of the developers.
  • I took a team lead position so I now lead a group of 3 developers. I didn’t expect that at the start of last year, but it has actually been a great thing.
  • I started mentoring 2 other developers under a mentorship program at work. This started towards the end of the year, but I think it is going to be a great program. I think it will be a valuable part of onboarding new hires in the future when we hire people right out of university.

Spring autowiring name collisions

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 came across a weird and interesting issue today. We currently use field level injection to inject our components into our code. In the case of JPA we have something like a @Service which injects our component and into the service and then uses it for the database operations. We do the same thing our custom cassandra annotations. While we are working on this project we are going to for a time be writing to both the SQL database and the Cassandra datastore. At some point we will then switch to reading the data out of Cassandra and then later on drop the SQL tables and remove the JPA Entities entirely. The problem I am seeing is lets say we have 2 Entities:


package com.haskovec.persistence.jpa;

@Entity
public class Person {

@Id
Integer personId;

@Column
String name;
}

package com.haskovec.persistence.cassandra;

@CassandraEntity
public class Person {

@Id
Integer personId;

@Column
String name;
}

We have 2 distinct objects based on package name, but the objects have the same name. In this case we have 2 Repositories as well based on them for the @CassandraRepository and @Repository. The problem I am seeing is that Spring is having trouble qualifying which repository to inject. According to the documents for @Inject and @Autowired they are supposed to wire based on type. Instead I am getting an error where it can’t qualify which bean to wire which makes it look like it is wiring by name. I was able to fix it with the @Qualifier annotation and naming the @CassandraRepository with an @Component("cassandraPersonRepository") annotation.

I don’t really like this fix though. In theory since these are distinct types Spring should be able to auto wire them correctly. According to the Spring documentation wiring by name is done primarily through @Resource but if that were the case then a service injecting 2 repositories of the same name from a different package should work. Then I found this in the documentation:

If no name is specified explicitly, the default name is derived from the field name or setter method. In case of a field, it takes the field name; in case of a setter method, it takes the bean property name.

This makes me think it is wiring by name inspite of what the documentation says about wiring by type for @Autowired and @Inject. Then I found section 6.10.6 of the documentation. The following quote is telling:

When a component is autodetected as part of the scanning process, its bean name is generated by the BeanNameGenerator strategy known to that scanner. By default, any Spring stereotype annotation ( @Component, @Repository, @Service, and @Controller) that contains a name value will thereby provide that name to the corresponding bean definition.

If such an annotation contains no name value or for any other detected component (such as those discovered by custom filters), the default bean name generator returns the uncapitalized non-qualified class name.

So based on this both classes would be named personrepository hence the problem qualifying the bean. So now my thinking is that to fix this without using @Qualifier in my code I will need to implement a custom bean naming strategy by implementing BeanNameGenerator and passing that to the component scanner. The obvious fix to me seems to be to generate the name with the package name plus the class name so that classes of the same name resolve differently under spring. I will need to test it out to see if that works but I am guessing it will.

Field injection is not evil

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.

Argument 1: “It’s a null pointer begging to happen

In Oliver’s example he MyCollaborator into MyComponent with the @Inject tag that you would use in Spring or in CDI. Then his argument is that a person would instantiate MyComponent outside of the Container with MyComponent component = new MyComponent().

My first thought is, you are dealing with a container managed component if you have @Inject in it so if someone is standing up the component outside of the container to me that already says they are doing something wrong. Given that I don’t find this a compelling argument. If you are using the component in a framework as it is designed to be used the framework will tell you if it can’t wire up the component due to missing dependencies, whether your container is Spring or it is JavaEE.

I suppose one could imagine designing a component that could be used in either Spring or CDI or standalone without a framework, and Oliver’s constructor example could still work (assuming you don’t blow up on the missing @Inject annotation which I think could happen.) So in my opinion this argument isn’t really valid or a big concern as is someone is misusing your component I am not too concerned with them getting a null pointer in that scenario.

Let’s consider his benefits of Constructor Injection. The first case is you can only create your component by providing all the dependencies. This forces the user of the component to provide everything. While I consider this a valid argument, I think the point is somewhat moot since we are talking about designing a component that already has a lifecycle to it and that a framework will inject the dependency for.

His second benefit is that you communicate mandatory requirements publicly. I have to admit I find this his most compelling argument. I don’t have a counter argument to this.

His third argument is that you can then set those fields final. I have to admit I do like making everything final so that is also a compelling argument to me. But not enough to counter the negatives of it.

Let’s consider the argument that he tries to dispel:

An often faced argument I get is: “Constructors just get too verbose if I have 6 or 7 dependencies. With fields only, this is fine”. Awesome, you’ve effectively worked around a clear indicator that the code you write is doing way too much. An increase in the number of dependencies a type has should hurt, as it makes you think about whether you should split up the component into multiple ones.

I don’t buy his counter argument here. In the project that I am working on we have a bunch of service level business logic components. We have a thin service layer that we expose to the presentation tier, and then do all the heavy lifting of our business logic in these hidden service level components. Given the high volume of business logic code we have we compose the different operations with injected reusable business logic components. This is also a huge benefit when working with a large team you get less merge conflicts as the code is spread out across more files and when you are onboarding new employees you have a lot more smaller business logic classes that are easier to digest than some massive classes with all this business logic in it.

If I split those components up that is what we have already done which is why we have to inject them all over the place to reuse those business methods. I think when dealing with a non-trivial app that is extremely large, breaking things into fine grained components that are reusable in multiple places actually leads to needing to inject more fields and not less.

Argument 2: Testability

In this case Oliver argues that you have to be doing reflection magic in unit tests if you use field level injection. To which I respond if you are running a dependency injection framework why wouldn’t you be using a dependency injection unit test framework. And of course we do. The answer is Mockito. With Mockito you structure your unit test like you would structure your component. So to test my service I might have something like below:

@InjectMocks final MyService service = new MyService();

@Mock Component requiredComponent;

@Test public void myTest() {

when(requiredComponent.methodCall()).thenReturn(new MockedResponse);

final boolean result = service.methodIAmTesting();

assertTrue(result);

}

Now I have a unit test that is structured largely like my service. The testing framework injects the mocked dependencies into our service we are testing and we wire up the results on the mocks so we can test our service. Again this strikes me as very testable as now I am writing tests that look a lot like the way my services themselves look.

So that is my argument against. Basically I think the number of arguments to the constructor actually does get extremely unreasonable in many real world scenarios where you have a lot of finely defined business logic components that can be composed in many different ways to solve the project. You do end up with a lot more boiler plate, and even if you use Lombok to hide it then you have ugly and somewhat cryptic Annotations to tell Lombok to put the @Inject annotation on the constructor. I think if you are running a dependency injection framework, it isn’t reasonable for people to instantiate those objects outside of that framework, and likewise it is very reasonable to expect your unit test framework to also be dependency injection driven.

Let me know if I have persuaded anyone to my point or if you think I am completely wrong and Oliver is right about this, I would love to hear someone explain to me why my arguments are wrong and why Oliver has been right all along, or if there is a 3rd even better way what that way is.

Spring Boot for prototyping

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.

Now my goal for this project is to create a higher level Cassandra abstraction for our system. Often in Cassandra we create multiple tables to represent the same data. The reason is depending on how you structure the data in CQL determines what queries you can run. We have the need to query some tables in many different ways so we need multiple tables to be able to answer the questions that we could in the SQL world. In our architecture we don’t want the developer to worry about which table they need to query for a given question, we would like to present this more like a standard JPA entity where the developer doesn’t need to worry about it and we abstract away which particular table is being queried or which tables are being saved to.

One of the initial thoughts of this project was to use Spring Data Cassandra. The advantage of that is we would have a third party library we could use so we wouldn’t have to maintain the low level Cassandra code. At one point I was considering ripping out our custom Cassandra Data layer and just using the Spring Data one (prior to this project) as ours is so close to what they are doing anyway why should we maintain that code when there is a perfectly good library we could use and we are already using Spring Data JPA. Right now I am not sure if I want to do that anymore though. If I go with Spring Data Cassandra each of the underlying tables would need to be modeled as a separate entity like our current framework. In that case then I would need a second layer on top if I am trying to present 1 domain object backing multiple tables so this seems like it isn’t ideal for what we are thinking. Another thing I am not 100% on with Spring Data Cassandra is that it isn’t backed by Pivotal. It is a community plugin. That isn’t necessarily a problem but I do have concerns about how up to date it will be. One way to look at this is maybe I should be involved in the plugin since clearly I could be working on that as well, but I get a little concerned about if it will be around otherwise. I noticed that the Spring Data Cassandra project is built off of the Datastax 2.0 driver. So if we are running off of Cassandra 2.1 (which we probably will be by the time this project goes live) we aren’t necessarily taking advantage of the new features. Again I could submit a pull request to update it, but given that I am not sure this is the right approach anyway at this point I haven’t decided to go this route (though that may change). Another thing I noticed is Spring’s initializr doesn’t list Cassandra as an option out of the box. Though I suspect if you checked JPA and then added the Spring Data Cassandra to your maven pom or Gradle file it would probably work.

So how does this tie into Spring Boot? Well I am not a big design everything up front kind of person. I tend to like to play around in code to come up with my design ideas. So I decided I want to prototype against what we are doing so I can see how this design would play out in code. I downloaded a new Spring project from the initializr with AOP, JAX-RS, Actuator, and Shell support. I then pulled our code for our Cassandra layer into there and added the Cassandra driver to the maven pom. I updated the application.properties file with my Cassandra database properties and low and behold I was up and running with a framework to test all of my changes in. Even though I have played around with boot, seeing myself able to build a sandbox to play around with this design in so quickly was very impressive to me. So now I can evolve this design without messing up our current code base and when I get to something I am happy with I can just bring those changes into back into our branch and we will be ready to go with our new design. So even though I am stuck with a monolith and I couldn’t easily bring boot into our main product the design of our project is such that it was very easy to pull that whole layer into this project and just be up and running with almost no configuration (aside from setting up the Cassandra connection properties).

So as usual I think Spring Boot is the bomb and everyone should be using it. I look forward to seeing where this design takes me. Once I have my high level sorted out I may try playing with dropping Spring Data Cassandra in the low level to see if we want to use that as our base, but my current guess is we won’t end up going that route.

Spring 4.1 finally!!!

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.

The first thing I did on Monday was to clone that repository and fix a couple of broken unit tests I had in it and then install it locally in our nexus server. Next up I updated the pom files to use my new version of the plugin and added the <proc>none</proc> config option that was introduced in aspectj 1.8.2. I fired up my local environment to test everything and discovered one of the major features of the app was broken. It looks like the way Spring 4.1 handles the ConverterFactories. We use a lot of Hibernate UserTypes in our app to map things to enums. The enums implement a common interface that handles the mapping between the storage of that enum and the value. With a little tweaking on how those enums were used I was able to get Spring to convert them correctly again using our Converter Factories.

I was thinking everything was good to go at this point and my testing discovered that our new feature that is Angular.js driven was broken. After much tracing and debugging I determined that some @ResponseBody parameters that in Spring 4.0 would accept an empty string in 4.1 that empty string was converted to a null and then the method was failing. I marked those methods to be @ResponseBody(required = false) and we were back up and running.

By this point it was already Wednesday morning. So I submitted the code to git and let jenkins run our tests on it. I immediately started getting some unit test failures saying that it couldn’t find the aspectOf() factory method. This didn’t make any sense as when you do compile time aspect weaving this method is supposed to be automatically added to your classes. I ended up digging through the aspectj source code as my first thought was what if somehow @Aspect isn’t being processed when you turn off annotation processing. I wasted way too much time down this path before I realized that it wouldn’t make sense as the whole point of ajc is to compile the aspects. Then in digging through the jenkins build log I realized what was really happening. The maven-java-compiler plugin 3.1 was actually running after the ajc compiler thus rewriting my woven classes with unwoven classes. When researching this issue I see a lot of people set the java-compiler plugin under maven to be <phase>none</phase>. We have ours set to test-compile with the ajc compiler set for the compile phase. When I tried to move test-compile to the ajc compiler it didn’t like some things we were doing with generics. I feel like the ideal fix would be to do that and don’t use the maven one at all. But since I just wanted to get this in and working I just reverted back to the maven-java-compiler version 2.5.1 which doesn’t seem to fire up again and rewrite the class. Todo for the future will be to try to entirely use the ajc compiler for the modules which need aspects woven into them.

After I had the aspectj issues solved I started seeing out of memory errors in our unit test phase. I banged my head on this for a day and a half before I figured out for some reason the combination of powermock-1.6.2 and junit-4.12 seem to be leaking memory or not shutting down some threads that are fired up when running the test. I tested going back to powermock-1.5.6 and junit-4.11 (since 4.12 isn’t compatible with powermock-1.5.6) and finally everything was happen and working. It was code reviewed yesterday and is now merged into master. So I am pretty excited to finally have reached the end of this project. I am hoping that the aspectj-maven-compiler will be resurrected from the dead and brought into mojohaus with my fix so that I can go away from my forked copy, but time will tell on that. Up next will be figuring out how to migrate to Spring Security 4.0.

JHipster webinar

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.