Spring Boot: What to do when Autowired stops working

That’s weird! Suddenly, you try to inject a dependency in your Spring Boot application, but it’s like @Autowired stopped working.

You will see this in several ways. IntelliJ will provide a warning from the Spring plugin, which says “Could not autowire. No beans of ‘YourBeanName’ type found.”

At runtime, Spring itself will fail with a message like:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.scottshipp.www.YourBeanName' available: expected at least 1 bean which qualifies as autowire candidate.

If this behavior looks familiar, please read on…

Play Framework Full Stack Development Video Tutorial

I’ve created a set of three videos covering a simplified introduction to Play Framework.

In the first video, we download and setup the Play Framework and build a web service.

In the second video, we add a database and connect our web service to the database so that data can be retrieved.

In the third video, we create a small UI with HTML, CSS, JQuery, and MustacheJS that allows users to look up data and renders a nice result.


Strongly-typed Java disaster prevention in Scala

For today’s entry on the weblog we take a short excursion down null- and validation-checking certain-disaster lane and emerge out the other side victorious.

I was writing some Scala code yesterday. Unfortunately it interfaces with Java code (ew! yeck! boo! hiss!) so almost immediately I became mired in null-checking everything constantly. I also had to check for valid values since some of my particular variables didn’t make sense unless they were in a specific range.

Since I shouldn’t show you that code, let’s just pretend like this is the code:

object InputValidator {

  def validateInput(customerComments: String, customerEmail: String, starRating: Int) = {
    require(customerComments != null && customerComments.length > 0 && customerComments.length < 1000)
    require(customerEmail != null && customerEmail.length > 0 && isValidEmail(customerEmail))
    require(starRating != null && starRating >= 1 && starRating < = 5)

    //add'l code elided
  def processCustomerComments(customerComments: String) = {
    require(customerComments != null && customerComments.length > 0 && customerComments.length < 1000)
    //add'l code elided for example
  def sendThankYouEmail(customerEmail: String) = {
    require(customerEmail != null && customerEmail.length > 0 && isValidEmail(customerEmail))
    //add'l code elided for example
  // so on and so forth ... ad infinitum

There were many more methods than these. They were called from various places in the client/calling code. And this was simplifying and cleaning up the calling code quite a bit. But, since all the values were bare types like String and int, I was putting these require statements at the top of every method to make sure no accidental bullshit like a NullPointerException would happen.

Since that choice made my Scala code obviously suck hard, I next tried making all method parameters of type Option, but I was bothered by the conviction that I should not semantically convey to my clients that any of these were optional when all fields were required. It also didn’t solve the problem of the further valid length and value checking that needed to happen. Another approach I briefly considered was the PartialFunction one.

Unfortunately, neither solution solved another issue, which is that the code still would not be DRY. Any change in the accepted-valid input, like changing star rating to accept the values 1 to 10, would create a situation where I had to go back and change validation logic everywhere it appeared.

Then I had a new idea: tiny types!

Tiny types to the rescue!

Continue reading “Strongly-typed Java disaster prevention in Scala”