Forem: Jeet Prakash

Getting Started with MQTT

Jeet Prakash — Sat, 06 Jun 2020 18:47:40 +0000

MQTT is a light-weight publish and subscribe protocol which allows low energy devices to exchange messages among each other. It is a simple messaging protocol design for resource constrained devices having low bandwidth. And hence it has found wide adoption on devices for Internet of Things (IoT) as it enables the IoT devices to receive control commands to do various things like turning the lights on or off.

There are many brokers available that implement MQTT protocol. I will be using Mosquitto Broker for the purpose of this and future posts.

Setting up Mosquitto MQTT Broker

Head to the official Mosquitto Downloads page for installing MQTT broker on your Windows or Linux machine. Or if you are more comfortable with docker you can also download and run the official docker image from Docker Hub as well.

docker run -it -p 1883:1883 -p 9001:9001 eclipse-mosquitto:latest

This command will download the eclipse-mosquitto image and start the container which will listen on port 1883 for incoming connections.

Connecting to Mosquitto MQTT Broker

Now that we have set up the Mosquitto MQTT Broker we are ready to publish messages to it. When we install the Mosquitto broker from its official downloads page it installs the CLI based MQTT client as well which allows us to publish messages and subscribe to the Mosquitto MQTT Broker.

With the following command we can subscribe to the broker:

> mosquitto_sub -t mqtt/test

And to publish the message to broker we can use this command:

> mosquitto_pub -t mqtt/test -m "Hello MQTT"

In both of the above commands we have used -t flag to specify which of the topics to subscribe and publish to. By default both commands will try to find the broker at localhost, if we want the clients to connect to a broker located somewhere else we can use -h flag for that. Also the message to be published can be specified by -m flag.

And as soon as we publish a message on terminal running publish client we see the same message appear on the terminal running subscriber client.

There is a lot more to MQTT that I have not covered in this post like Topic Levels, Message Encryption, Message Retention and much more. But these would surely be the topics for future posts. So stay tuned!

This article is already published on my personal blog.

What is Application Scalability?

Jeet Prakash — Sat, 30 May 2020 15:34:32 +0000

So you got this brilliant idea that you just converted into an app and deployed on one of the instances that you just bought on a cloud platform. Initially your app is not that famous and has a low user base but everything seems to be running fine with the app.

Slowly as the time goes by your app starts to get famous and your user base starts to grow with that too. So much so that during the peak hours the load becomes so high that some of the users start to experience request timeouts.

You check the resource utilization on that instance and find out that during peak time the CPU was sweating it out at 100%. So now you know the reason for those request timeouts, but what would you do to get around that? Thinking about the resource utilization, you reconfigure your instance to have more compute power and more memory. Once done, you notice that none of your users are now reporting request timeout issues they were having earlier.

A few more days went by and your users started to report the same old issue of request timeouts and slowness in the app. But you reconfigured your instance to have more compute power and you thought it was more than enough. You again check resource utilization and find out that the CPU is again working at 100% not just because a lot more users are using the app but spending more time interacting with it. So would you be adding more power to your instance? The number of users will only go up in the future and sooner the app just won’t be able to withstand the load from all of those additional users.

Enter Scalability

Application was facing the problem because one single instance was getting stretched out of its resources. As a solution we need to scale the application so that it can withstand sudden peaks in usage.

The simplest solution would be to add more CPU and memory to the instance so that it can use those additional resources whenever there are usage peaks, the same approach we have been trying in above example, this approach of scaling application is known as Vertical Scaling. While this approach will solve the problem at hand, adding more hardware to the box always comes with an upper limit. And merely praying that this upper limit never gets hit in future is certainly not the best approach!

Another solution would be to have multiple smaller instances with each instance running your application. This way we can dynamically increase the number of instances to handle sudden spikes in usage and dynamically remove them as soon as usage gets normal. This approach of scaling application is known as Horizontal Scaling and is more suitable for modern cloud environments as it entertains usage as per requirement.

Horizontal Scale or Vertical Scale?

Horizontal scaling warrants using load balancer in front of the instances serving the application. And these load balancers will be responsible to distribute the load evenly among every instance of application. With a vertically scaled solution we don’t have to worry about load balancers.

The horizontal scaling solution is more resilient towards failures as we are having multiple instances of application running and other instances can handle the load in case one of them fails. On the contrary the vertical scaling solution presents a single point of failure as it is running on only a single instance.

There is no clear answer as to which one to choose. Both of these approaches come with their own pros and cons. Vertical scaling is preferable while the product is in the initial stages and the user base too is not large. But as the product gets mature and starts getting more exponential load we would need to have our application to scale horizontally.

This article is already published on my personal blog.

Getting Started With Hibernate

Jeet Prakash — Sat, 30 May 2020 15:30:48 +0000

Hibernate is one of the most famous Object-Relational Mapping (ORM) tool that allows a developer to easily map specialised Java objects, known as Entities, to database tables while also enabling him/her to create new rows on database tables and/or update the existing ones via those Java objects. This capability greatly reduces the development time as now we don’t have to take care of each and every intricate detail about how the data is being created, updated and deleted on the database. And it need not saying that an awesome framework like Hibernate provides a lot more than just that.

In this post we will be setting up a simple Java project to get started with Hibernate. But we will not be using a Web MVC framework like Spring on top of Hibernate because using any other framework will be a distraction for understanding Hibernate itself. So we will be creating a standalone Hibernate application and use JUnit for unit testing each Hibernate feature we learn. As our first example we will be inserting a record on User table in a local MySQL server. So lets get started!

Create a Maven Project

Start by creating a maven project on your favourite IDE and edit the pom.xml file to have the following Hibernate, JUnit and MySQL (since we are using a MySQL database) dependencies. The final pom.xml file would look like this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.jeetprksh</groupId>
  <artifactId>hibernate-examples</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>hibernate-examples</name>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>8.0.11</version>
    </dependency>

    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-core</artifactId>
      <version>5.2.10.Final</version>
    </dependency>
  </dependencies>

</project>

Configuring Hibernate

Any Hibernate application would want minimal configuration that tells it what database to use and where to look for it. We configure all of that information in hibernate.cfg.xml file:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD//EN"
        "http://hibernate.sourceforge.net/hibernate-configuration-5.0.dtd">

<hibernate-configuration>
    <session-factory>
        <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
        <property name="hibernate.connection.url">jdbc:mysql://localhost:3306/testDB</property>
        <property name="hibernate.connection.username">root</property>
        <property name="hibernate.connection.password">qwerty123</property>
        <property name="hibernate.connection.pool_size">10</property>
        <property name="show_sql">true</property>
        <property name="dialect">org.hibernate.dialect.MySQLDialect</property>
        <property name="hibernate.current_session_context_class">thread</property>

        <mapping class="com.jeetprksh.hibernate.entity.User" />
    </session-factory>
</hibernate-configuration>

Apart from having database connection details it is also having details for mapped Entities. We need to keep this file in maven’s resource directory so that we have it on classpath. Now in our Java application we will read out this configuration to create an instance of SessionFactory which will be used to create and manage Session which in turn provides a CRUD interface for mapped Entities. The overall Java configuration class would be:

public class HibernateConfig {

  private static final SessionFactory sessionFactory;

  private static ServiceRegistry serviceRegistry;

  static {
    try {
      StandardServiceRegistry standardRegistry =
              new StandardServiceRegistryBuilder().configure("hibernate.cfg.xml").build();
      Metadata metaData = new MetadataSources(standardRegistry).getMetadataBuilder().build();
      sessionFactory = metaData.getSessionFactoryBuilder().build();
    } catch (Exception e) {
      e.printStackTrace();
      throw new ExceptionInInitializerError(e);
    }
  }

  public static SessionFactory getSessionFactory() {
    return sessionFactory;
  }
}

Entity Class

The entity class is a special Java class which represents a database table in our Java application and any CRUD operation that we need to on that database table would be done through this entity class. Since we need to insert a record into user table we will be creating a User entity class that would look like this:

@Entity
public class User {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private int id;

  private String firstName;

  private String lastName;

  private int age;

  public User(String firstName, String lastName, int age) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.age = age;
  }

  // getters and setters

}

Notice that our User class is using following Hibernate annotations:

A class level annotation @Entity which makes it an Entity mapped with the table having similar name. If name of entity class and that of table needs to differ then we can specify table name in optional annotation parameter as @Entity(name = "user_table").
With @Id annotation on id attribute we are making it the unique identifier for User entity.
@GeneratedValue decides how the unique identifier would be generated while inserting new records into User table.

Creating the DAO Layer

Data Access Object would be the single point of contact for whole application for updating and querying records to and from database. In our case the unit test cases will be using these DAOs for same. Since we need to insert a user entity the corresponding UserDao will look like this:

public class UserDaoImpl extends CommonDaoImpl implements UserDAO {

  @Override
  public int createUser(User user) throws HibernateException {
    return super.saveEntity(user);
  }

}

Notice that UserDao will only be having data access methods specific to User entity, so if we are having another entity, say Address, it will require its own DAO class, AddressDao. But these DAOs are dependent on more generic CommonDao which would be communicating directly with Hibernate for saving, querying and updating entities.

public class CommonDaoImpl {

  private SessionFactory sessionFactory;
  private Session session;

  public CommonDaoImpl() {
    this.sessionFactory = HibernateConfig.getSessionFactory();
    this.session = sessionFactory.getCurrentSession();
  }

  protected int saveEntity(Object obj) throws HibernateException {
    Transaction transaction = session.beginTransaction();
    int id = (Integer) session.save(obj);
    transaction.commit();
    return id;
  }
}

Each method in this DAO would be responsible for starting a transaction on an instance of Session object, save the Entity on same Session instance and then commit the transaction.

Putting It All Together

Finally, we have configured and implemented all the necessary things and now it is time we put in the final piece to see it all in action, the unit test.

public class Tests {

  private static final Logger logger = Logger.getLogger(Tests.class.getName());

  private UserDAO userDao;

  public Tests() {
    this.userDao = new UserDaoImpl();
  }

  @Test
  public void testInsertUser() {
    User user = new User("Robb", "Stark", 17);
    Integer id = (Integer) userDao.createUser(user);
    assertTrue(id instanceof Integer);
  }
}

Notice that for unit testing the insert User our unit test case is first making the User object and giving it to the DAO layer to get it inserted into database. The DAO layer will return the unique identifier of the record just inserted which we will use as the pass/fail criteria for this unit test.

Code

Working code has been committed on this github repository.

This article is already published on my personal blog.

Why Design Patterns?

Jeet Prakash — Sat, 30 May 2020 15:28:03 +0000

Somewhere in Kings Landing, Tyrion and Bronn were discussing their strategy for an upcoming Software Design tourney.

Tyrion: Ser Bronn of Blackwater! I am sure you are all prepared for the upcoming tourney.

Bronn: Oh! I will be surprising all the knights with this new thing I am working on.

Tyrion: Just like you surprised Stannis at Blackwater? I would want to know more about that!

Bronn: So there are these special client object that wants to get some task done, you know like cleaning a castle or opening the gates. And then there are some command object that know how to execute those task on other set of objects, so for example, OpenGateCommand will do open gate operation on Gate object. And you know what? That client object would not care about how the gate is opened.

Tyrion: Excellent! I am sure you are going to topple a knight or two with this kind of design. It reminded me of old days when I was Acting Hand of The King.

Bronn: But I wish I could have a name for this software design. Who’s going to wait for me to explain all this?

It is evident from above conversation that there is nothing called Software Design Patterns in Westeros. What Bronn was trying to convey to Tyrion can be easily termed as Command Pattern in our world, but since neither of them know what Software Design Patterns are they will always be having a hard time explaining things related to software design to each other.

An excerpt from wikipedia on Design Patterns:

"A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations."

So why should we care about using Design Patterns in our projects?

Shared Vocabulary

Design patterns adds on to a developer’s vocabulary so that he/she can easily communicate their ideas with fellow developers by saying more with less words. Other developers will know quickly what is being conveyed. For example, if both Tyrion and Bronn had a common understanding of Command Pattern, Bronn wouldn’t need to explain each and every aspect of what he is trying to do.

Avoid Reinventing the Wheel

Design Patterns are proven techniques and solutions for commonly recurring problems that are developed from hard experience of other developers, providing us with ready-to-use design templates. And that really helps us to design and implement flexible and maintainable solutions without reinventing the wheel.

Collection of Best Design Practices

The basic principles of object oriented programming namely Encapsulation, Abstraction, Polymorphism and Inheritance while these are perfect tools for designing software systems but doing so with the understanding of design patterns will further enhance them with additional design principles like "composition over inheritance", "encapsulate what varies" etc for creating flexible and future proof systems.

Helps you to stay "In Design"

Design patterns helps developers keep the discussion at design level and avoid the minute details about classes, objects, functions and methods. We should only care about these details during implementation phase and not in design phase.

Used by Frameworks and Libraries

It's not just that only we can leverage the power of design patterns to our advantage, but the famous frameworks and libraries are also using them to make our life simpler. For eg. JdbcTemplate and JmsTemplate in Spring framework are good examples of Template Pattern, also MapMaker in Guava library and StringBuilder in Java are perfect examples of Builder Pattern.

This article is already published on my personal blog.

No XML Spring and Hibernate Integration

Jeet Prakash — Sat, 30 May 2020 15:24:01 +0000

Back in the pre Spring 3.1 days, we had to configure each and every bean into one of the spring configuration files which only happens to be an XML. And so if we were building a web application with Spring which is also using a relational database to store all its data, we needed to create a bean tag into one of those spring configuration XML files for reading out database connection properties to create a data source bean, which we then feed as a parameter to yet another bean tag to create a database session factory bean.

In this post we will be building a small restful web application with Spring MVC integrated with Hibernate to fetch the user record from MySQL database server and display it as a JSON response on the browser, without writing a single XML file. Furthermore we will also be doing away with tomcat’s web.xml leveraging latest Servlet 3.1 APIs and doing all of that configuration in our Java classes. So what are we waiting for!

Configuring Spring and Hibernate Integration

We can start by making a maven project with webapp archetype into any of our favourite IDE. And in its pom.xml file we can give all the dependencies as per this gist. Notice that as one of the properties we have to set failOnMissingWebXml to be false so that we can safely delete web.xml file.

Now we can start with configuring DispatcherServlet for our Spring MVC application which we can do in a single class:

public class AppConfig extends AbstractAnnotationConfigDispatcherServletInitializer {

  @Override
  protected Class<?>[] getRootConfigClasses() {
    return new Class[] { HibernateConfig.class };
  }

  @Override
  protected Class<?>[] getServletConfigClasses() {
    return new Class[] { WebMvcConfig.class };
  }

  @Override
  protected String[] getServletMappings() {
    return new String[] { "/" };
  }

}

A couple of points to note here:

This class is extending the AbstractAnnotationConfigDispatcherServletInitializer which automatically configure DispatcherServlet and the Spring application context.
In getServletMappings() methods we return one or more paths that DispatcherServlet will be mapped to.
In getServletConfigClasses() we would be returning the @Configuration annotated classes that are having beans from which DispatcherServlet will be loading its application context.
Classes returned from getRootConfigClasses() will be used to configure other application contexts that are created by ContextLoaderListener and are shared among them.

This is all we need to configure our DispatcherServlet, now let's look into HibernateConfig.java and WebMvcConfig.java. In HibernateConfig.java we need to create all the beans that are necessary for handling interaction with database via Hibernate.

@Configuration
@EnableTransactionManagement
public class HibernateConfig {

  @Bean
  public LocalSessionFactoryBean getSessionFactory() throws PropertyVetoException {
    LocalSessionFactoryBean bean = new LocalSessionFactoryBean();

    Properties hibernateProperties = new Properties();
    hibernateProperties.put("hibernate.dialect", "org.hibernate.dialect.MySQLDialect");
    hibernateProperties.put("hibernate.show_sql", "true");

    bean.setHibernateProperties(hibernateProperties);
    bean.setDataSource(getDataSource());
    bean.setPackagesToScan("com.spring5.app.dto");
    return bean;
  }

  @Bean
  public ComboPooledDataSource getDataSource() throws PropertyVetoException {
    ComboPooledDataSource dataSource = new ComboPooledDataSource();

    dataSource.setDriverClass("com.mysql.cj.jdbc.Driver");
    dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/app-db?useSSL=false");
    dataSource.setUser("root");
    dataSource.setPassword("qwerty123");
    dataSource.setAcquireIncrement(10);
    dataSource.setIdleConnectionTestPeriod(0);
    dataSource.setInitialPoolSize(5);
    dataSource.setMaxIdleTime(0);
    dataSource.setMaxPoolSize(50);
    dataSource.setMaxStatements(100);
    dataSource.setMinPoolSize(5);

    return dataSource;
  }

  @Bean
  public JdbcTemplate getJdbcTemplate() throws PropertyVetoException {
    JdbcTemplate template = new JdbcTemplate();     
    template.setDataSource(getDataSource());        
    return template;
  }

  @Bean
  public HibernateTransactionManager getTransactionManager() throws PropertyVetoException {
    HibernateTransactionManager transactionManager = new HibernateTransactionManager();
    transactionManager.setSessionFactory(getSessionFactory().getObject());
    return transactionManager;
  }

}

In WebMvcConfig.java we need to create web specific beans, so as we are creating restful endpoints we would need appropriate message converters that would be required to convert Java objects to their proper JSON representations.

@Configuration
@EnableWebMvc
@ComponentScan("com.spring5.app")
public class WebMvcConfig extends WebMvcConfigurationSupport {

  @Override
  public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
    converters.add(customJackson2HttpMessageConverter());
    super.addDefaultHttpMessageConverters(converters);
  }

  @Bean
  public MappingJackson2HttpMessageConverter customJackson2HttpMessageConverter() {
    MappingJackson2HttpMessageConverter jsonConverter = new MappingJackson2HttpMessageConverter();
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
    jsonConverter.setObjectMapper(objectMapper);
    return jsonConverter;
  }

}

Implementing REST and Persistence Layers

Now that we have configured all the important parts of our application we now need to implement a REST controller and corresponding Service and DAO that are quite straightforward.

@RestController()
@RequestMapping("user")
public class UserController {

  @Autowired
  private UserService service;

  @RequestMapping(value = "{userId}", method = RequestMethod.GET)
  public @ResponseBody ServerResponse getUser(@PathVariable("userId") Long userId) {
    return this.service.getUser(userId);
  }
}

@Repository
public class UserDaoImpl implements UserDao {

  @Autowired
  private SessionFactory sessionFactory;

  @Override
  public UserDTO getUser(Long userId) {
    TypedQuery<UserDTO> typedQuery = sessionFactory.getCurrentSession().createQuery("from UserDTO where id=" + userId.toString());
    return typedQuery.getSingleResult();
  }

}

And finally our service class is doing some mission critical stuff!

@Service
public class UserServiceImpl implements UserService {

  @Autowired
  private UserDao userDao;

  @Override
  @Transactional(readOnly = true)
  public ServerResponse getUser(Long userId) {
    ServerResponse response = new ServerResponse();

    UserDTO dto = userDao.getUser(userId);
    response.setUser(new User(dto.getFirstName() + " " + dto.getLastName(), 
                        new Long(dto.getAge())));

    return response;
  }

}

Database schema

Lastly for the application to work we also need to create database schema in our MySQL server:

create table if not exists `users` (
  `id`      int not null auto_increment,
  `firstName`   varchar(20),
  `lastName`    varchar(20),
  `age`     int,
  primary key (`id`)
);
insert into `users` values (1, "john", "doe", 29);

Source Code

I have not put all of the code on this post, but you can check out the working project from this github repository.

This article is already published on my personal blog.

Embedded H2 Database with Spring Boot Application

Jeet Prakash — Sat, 30 May 2020 15:20:12 +0000

It’s a well known fact that when we are building a web application it is nearly impossible to do away with some form of data storage. There's got to be a database, relational or non-relational, where we need to store the business data to be retrieved and used later. Desktop applications too might require some useful data to be be stored locally like application settings, cached data from servers etc.

H2 is one of the lightweight and open source relational database management system written in java and can be easily embedded in java applications or run in client server mode. In this post we are going to use H2 database embedded in a Spring Boot application. And for the sake simplicity we will only creating a dummy application setting record on out embedded H2 database and then retrieving the same record. So let’s begin!

Setting up Spring Boot project

Setting up a Spring Boot project is quite easy. Head to Spring Initializr website and fill in the appropriate details on left under "Project Metadata". Under "Dependencies" fill in H2 and JPA as dependencies and hit "Generate Project". This will download a preconfigured spring boot project that we can open with our favourite IDE.

Once we have our initial project setup with IDE, we can start adding more details on it.

Adding JPA Repository and Entity

Next up is adding database Entity and corresponding Spring Data JPA Repository to do CRUD operation on that repository. Since we have decided to save application settings into embedded H2 database we would need to create an entity class for Application Settings.

package com.jeetprksh.h2.boot.entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class ApplicationSetting {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    private String userEmail;
    private boolean cachingEnabled;

    ApplicationSetting() {

    }

    public ApplicationSetting(String userEmail, boolean cachingEnabled) {
        this.userEmail = userEmail;
        this.cachingEnabled = cachingEnabled;
    }

    @Override
    public String toString() {
        return "ApplicationSetting{" +
                "id=" + id +
                ", userEmail='" + userEmail + '\'' +
                ", cachingEnabled=" + cachingEnabled +
                '}';
    }
}

And declare a Spring Data Repository interface.

package com.jeetprksh.h2.boot.dao;

import com.jeetprksh.h2.boot.entity.ApplicationSetting;
import org.springframework.data.repository.CrudRepository;

public interface AppSettingRepository extends CrudRepository<ApplicationSetting, Integer> {
}

Now we need to Autowire this repository and do the saving and fetching of application settings.

package com.jeetprksh.h2.boot.app;

import com.jeetprksh.h2.boot.dao.AppSettingRepository;
import com.jeetprksh.h2.boot.entity.ApplicationSetting;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.domain.EntityScan;
import org.springframework.data.jpa.repository.config.EnableJpaRepositories;

import java.util.logging.Logger;

@SpringBootApplication(scanBasePackages = "com.jeetprksh.h2.boot")
@EnableJpaRepositories("com.jeetprksh.h2.boot")
@EntityScan("com.jeetprksh.h2.boot")
public class Application {

    private static Logger logger = Logger.getLogger(Application.class.getName());

    @Autowired
    private static AppSettingRepository repository;

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
        repository.save(new ApplicationSetting("abc@def.ghi", true));
        repository.findAll().forEach(setting -> {
            logger.info(setting.toString());
        });
    }

    @Autowired
    public void setRepository(AppSettingRepository repository) {
        Application.repository = repository;
    }
}

Note: I decided to add/retrieve the settings in the configuration file itself, but it would have been better off in an appropriate service.

Setting Application Properties

Our application would require following properties:

# Datasource
spring.datasource.url=jdbc:h2:file:~/embedded-db
spring.datasource.username=sa
spring.datasource.password=
spring.datasource.driver-class-name=org.h2.Driver

# JPA
spring.jpa.hibernate.ddl-auto=update

Spring.datasource.url: Here we give the connection URL to the database. Since we are using embedded H2 database which saves all of its data in local file system we will be giving in the path to the file which will be used to store data. In our case this file will be in user’s home directory.
Spring.datasource.username: The user name for H2 database.
Spring.datasource.password: Password for database, by default it does not have one.
Spring.datasource.driver-class-name: The driver class that would be used.
Spring.jpa.hibernate.ddl-auto: Setting this property to “update” will enable application to use existing database and not drop the database on each startup.

Running the Project

There are numerous ways to run a spring boot project. Let’s do it with creating executable jar with maven, following commands would do it:

mvn package
cd .\target\
java -jar .\h2-springboot-embedded-0.0.1-SNAPSHOT.jar

Notice that after running this application a file will be created in user home directory with name embedded-db.mv.db which will be having our database schema and all the records we will be saving into it.

Code

All the working code for this project is available on this github repository.

Useful Links

This article is already published on my personal blog.