When you hit GRUB console on boot in an ASUS VivoMini UN45 with Ubuntu 18.04

Posted by on January 10, 2021 No comments

I have an ASUS VivoMini that I run Ubuntu 18.04 on as a place for databases, Docker containers, and other stuff. Every now and then it boots me into GRUB console on reboots.

I’m here going to show how I use to solve is:

grub> set root=(hd0,2)
grub> linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2
grub> initrd /boot/initrd.img-4.15.0-112-generic
grub> boot

Explanation:
set root=(hd0,2) sets the disk an partition where the Linux installation is. Here is the first drive (hd0) and the second partition (2)
linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2 here I set the Linux kernel and the root path. It’s where I usually mess up. Most guides tell you to use /dev/sdaX (or sdbX or similar). The problem is that I use an internal Intel SSD witch identifies as nvme0 and not sda2, so when I try to use sda2 I get: “Gave up waiting for root file system /dev/sda2 does not exist. Dropping to shell”, but when I use nvme0n1p2 it works (nvme0n1p2 means first disk (n1) and second partition (p2))
initrd /boot/initrd.img-4.15.0-112-generic sets the initrd file. This has to be the same version as the vmlinux version
boot simply boots the system with the settings above. If all goes well we should reach the Ubuntu login screen (or console)

To make the changes permanent (until the next power outage or other misfortune) 

sudo update-grub

This will collect all data from the settings above and create a grub.cfg file. I needed sudo on my system, maybe you don’t. After we have created a new grub.cfg file we need to install it on the disk boot sector (not on a partition so no number for disk or partition here). For me, this was done by:

sudo grub-install /dev/nvme0

The system should now behave again 🙂

Tested on Ubuntu 18.04, GRUB 3.0, and Linux kernel 4.15.0-112

Mock nested method calls using Mockito in Spring Boot

Posted by on November 27, 2020 No comments

Quite often you have a nested call chain to get a result in Java. Mocking these in a test is a little different than mocking just one call. I’m here going to show a solution to that.

Say you have the following call chain to create a transacted session for a JMS connection:

Session session = 
           connectionFactory.createConnection()
                            .createSession(Session.SESSION_TRANSACTED);

To mock these calls we have to break them apart and mock them one by one

    
...
public MyTestClass {
  @Mock
  private Session session;

  @Mock
  private ConnectionFactory connectionFactory;

  @Mock
  private Connection mockedConnection;

  @BeforeMethod
  public void setUp() throws JMSException {
    MockitoAnnotations.initMocks(this);
    Mockito.when(connectionFactory.createConnection())
                                          .thenReturn(mockedConnection);
    Mockito.when(mockedConnection.createSession(
                                           Session.SESSION_TRANSACTED))
                                          .thenReturn(session);
  }
...

We are now ready to create all our tests 🙂

Tested on Java v1.8.0_252, Mockito v3.3.3, Spring Boot v2.2.4 and TestNG v6.11

Using a different Bean depending on profile in Spring Boot

Posted by on November 25, 2020 No comments

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