Spring: 404 errors on AWS Elastic Beanstalk (Tomcat)

I had run into a strange issue while trying to deploy a simple “Hello World” application on AWS Elastic Beanstalk. I had gone through all the guides available, set SERVER_PORT to 5000, made sure my main class was extending SpringBootServletInitializer and so on…

My application ran fine locally, I could see “Hello World” in my browser.

While looking at the Beanstalk dashboard, I noticed that it tells me the version of Tomcat and Java: Tomcat 8.5 with Java 8 running on 64bit Amazon Linux/3.2.2

Okay, so Elastic Beanstalk uses these Java versions… so I checked my pom.xml file, and noticed…

...
<java.version>11</java.version>
...

I changed it to 1.8 (Java versioning is weird and inconsistent… 1.8 is Java 8)

I then ran mvn clean package and re-uploaded my war file… and boom, “Hello World” appeared in my browser…

What’s funny is, I didn’t see anything in the Beanstalk logs indicating this was the problem! I just gave it a shot and it fixed the issue.

Are you getting 'undefined' errors in Vue, but devtools says the data is there? You may need conditional rendering.

You may run into a situation where, at some point in your app’s loading or initialization, some nested property on your data object is undefined. Perhaps you open up the devtools extension, and you see that the property is in fact, there.

What gives? You may need conditional rendering. Remember, JavaScript is asynchronous. You may be trying to access that data, before it’s even been loaded.

You can use conditional rendering to make sure that a component, or a block of HTML, is not rendered until a condition is met.

<div id='user-data' v-if="someCondition">
    ...
</div>

Say you have a data object with the property current_user:

data() {
    return {
        current_user: {}
    }
}

Initially, this current_user property is just an empty object. Later on in your app, you use API calls to put data in that property.

async mounted() {
    this.current_user = await this.axios.get("/my-api/user/1.json").data
}

Now you want to display the data:

<div id='user-data' v-if="Object.keys(current_user).length !== 0">
    <div id='user-name'>{{ current_user.name }}</div>
</div>

This block of HTML will be rendered only if there are any properties on this.current_user

There may also be situations where you need to declare a flag, such as:

data() {
    return {
        displayUsersList: false
    }
}

and then flip that switch elsewhere in your code, perhaps when a websocket connection has been made.

channels: {
    ChatRoomChannel: {
        connected() {
            this.displayUsersList = true
        }
    }
}

Perhaps you know that, in your application, you are ready to display the list of users after a websocket connection is made.

In your own app, you’ll need to determine where these conditions need to be flipped.

So, if you’re running into these kinds of issues, where you’re receiving errors saying that properties on your data object are undefined, then you may need conditional rendering. It’s up to you to figure out at what point of execution you’ll need to make the condition true.

You can also read the Vue documentation on Conditional Rendering for more information.

Is it just me, or do Google search results really suck these days?

If you try Googling something like, “what’s a good diet?”, you’re probably going to see healthline.com in the results, with an article titled something like: “5 Diets That Are Supported by Science – Healthline”

This is incredibly annoying to me, and it seems very common. This seems to occur with quite a variety of search terms as well. The primary goal of these websites is to put as many advertisements in your face as possible, rather than provide useful information. Providing useful information is secondary. The information in these kinds of articles is simply SEO keyword fodder, whatever garbage they can muster to pump out thousands of pages of content.

I feel like this is what Google has become. Mostly garbage. Nearly every result is something like “5 ways to X.”

Where has all the useful information gone? What happened to novel, useful information just for the sake of it?

I feel like, many moons ago, people would blog about things, and you would have novel ideas being shared. Certainly feels as if those times have passed.

For a while Google was very useful, but now there’s the big business of gaming the search results, and getting your results to the top of the list, so you can shove as many advertisements in peoples’ faces as possible.

Tips on probing log files after your Linux server crashes

When your Linux server crashes, one place to look is in /var/log/kern.log for clues as to what went wrong.

This file contains a lot of output that can be difficult to sift through. One way to navigate this log file, is by noting the first line of the log file.

The first line in my log looks like this:

May 29 09:18:24 lab kernel: [    0.000000] Linux version 4.15.0-1039-aws (buildd@lgw01-amd64-034) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #41-Ubuntu SMP Wed May 8 10:43:54 UTC 2019 (Ubuntu 4.15.0-1039.41-aw
s 4.15.18)

The log file starts off with a line about the Linux version. You can use this as a sort of anchor point for navigating through the log file. Now you know what line to search for in order to see where the server has stopped and started. When analyzing your log file, you can search for all occurrences of this line to understand where in the log file your server had restarted.

If you use the command less /var/log/kern.log it will open the log file in less, and you can navigate the output more easily.

When you type a forward slash in less, you can then enter some search terms, such as Linux version, and then you can use n and p to go to the next or previous occurrences of your search term.

Try searching for Linux version in the output, this allows you to navigate to the points within your log file at which the server has started. From these particular points in the log files, you can then look further up the log file to see if anything sticks out as to what may have caused your server to crash.

Vue: 404 connection refused errors in browser console

An issue I had recently was where I was seeing numerous errors in my browser console, that looked like this:

http://localhost:4000/sockjs-node/info?t=1555523570042 net::ERR_CONNECTION_REFUSED

If you’re seeing errors like these in your browser console, you’re probably running your Vue app using vue-cli-service which is a part of vue-cli. This is the development server basically, which serves your Vue app.

What you need to do to get rid of the errors, is you need to specify a port in your webpack config file. The webpack config file is located at vue.config.js in your project folder.

This is what I have in my vue.config.js file:

module.exports = {
    devServer: {
        disableHostCheck: true,
        host: '0.0.0.0',
        port: 4000
    }
}

Weird ESLint errors in vue-cli projects

If you’re getting weird errors such as the one below:

Module Warning (from ./node_modules/eslint-loader/index.js):
error: Parsing error: Unexpected token < at src/components/ChatApp.vue:1:1:
> 1 | <template>
    | ^
  2 |     <div>
  3 |           <div v-for="message in messages">
  4 |

You may need to install eslint-plugin-vue.

This tells ESLint about *.vue files, and how they are formatted. The error above is ESLint getting confused, because it doesn’t understand the structure of Vue’s single file components. Installing the eslint-plugin-vue module makes ESLint aware of *.vue files.