Using a different Bean depending on profile in Spring Boot

This is something that can be very useful when running your application in different environments. One case is that you want to place messages on a queue but you do not have access to the queue manager in the development environment. Here is an example of what a solution might be to that problem:

First, we create an interface that can act as a facade for our “send” method

public interface Gateway {
  void send(Message message);
}

Now we need to add this interface to our class

public class MQGateway implements Gateway {
  @Override
  void send(Message message){
    /* All the logic needed to send a message */
  }
}

And now we create two Beans. One for each profile

@Bean
@Profile("dev")
public MQGateway mqgatewayDevelop() {
  return new MQGateway() {
    @Override
    void send(Message message) {
      log.info("Mocked gateway. Sending message to log: " + message);
    }
  }
}

@Bean
@Profile("prod")
public MQGateway mqgatewayProduction() {
  return new MQGateway();
}

I usually put Bean creation in a configuration class so that any setting from application.yml is close at hand

And now we are going to use some “magic” to make Spring choose the right one

public class MyClass {
  @Autowire
  private Gateway mqGateway;

  public void myFunction(Message message) {
    mqGateway.send(message);
  }
}

So, how does this work. Well, by using the interface when calling the ‘send’ method we are forcing Sprint to find a suitable Bean of that type and since there only will be one active per profile Spring will find the right one.
If Spring can’t find a suitable Bean it will throw a exception

Tested on Spring Boot v2.2.4

Git: “Squash” your commits – alternative solution

Sometimes you will have a pull request that is full of merge commits mixed with regular commits. These branches are a little tricky to squash. I’m here going to show a trick that I sometimes use.

Stand in your pull request branch and run:

git reset --soft origin/master

This resets us back to master but keeps all our changes in staged, ready for us to commit in to one new commit:

git commit -m"My one commit message for all changes"

After this we need to replace all the commits in our pull request with the new one we have in our local

git push -f

We should now have only one commit in our pull request

Tested on Git v2.24.3 and OSX 10.15.6

Git: Squash your commits

When working on a pull-request that keeps getting updated with commit after commit you sometimes need too squash some commits to get a nicer history

I’m here going to show you one way to do just that using the interactive view of git rebase

git log --pretty=oneline

This could look something like this:

5d870be Added submit button
56f962c Added knockoutjs logic
5640719 Merge pull request #1148
5015685 Set encoding on property file
4ec2f9c Updated test database scripts
567cd41 Checkstyle fix
980be70 Added border to form
405fc82 Resolved conflict with main
52eb187 Fixed login div border
fc2b99b Fixed bugg with form validation
2f8f126 Updated JQuery version
0acd0fe Fixed flow test
4dfb2dd Added form validation test
3cc1247 Added xml parser

Now we look for a good place to squash. Let’s say that we for example want to squash row 1 to 5. To start the process we run:

git rebase -i 567cd41

We here choose the hash of the commit just below the one where we want to squash from. This will bring up your favorite editor (in my case VIM) where you can mark which commits you want to keep (‘pick’) and which ones you woulkd like to squash (‘squash’). You can even rearange you commits here – just make sure to rearange the hashes too 🙂 . Note! The order of commits in the editor is reversed. Older above and newer below

pick 567cd41 Checkstyle fix
squash 4ec2f9c Updated test database scripts
squash 5015685 Set encoding on property file
squash 5640719 Merge pull request #1148
squash 56f962c Added knockoutjs logic
squash 5d870be Added submit button

# Rebase 567cd41..5d870be onto 5015685 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

After you have made your changes you save and quit, and the rebasing operation starts.
This process can find conflicts that needs to be resolved, like any other rebase. You will also be asked to set the commit message of the squash. This messages will contain all of the commit messages so here is a good oppertunity to make them pretty and understandable 😉

NOTE! This solution might not play nice when there are merge commits present!

Tested on Git v2.24.3 and OSX 10.15.6