DEV Community: Erwan Le Tutour

HTML to PDF — Java

Erwan Le Tutour — Sun, 06 Feb 2022 12:33:50 +0000

Use Case

At the beginning of the year 2020, my wife wanted to redo her CV, so I offered to give her a small tool where she had only to inform her trainings, her diplomas and her experiences and who would then put them in a document.
At first I wanted to create a document in word format, but I was not satisfied with the rendering, the HTML of the frontend looked better than the final document, that’s when I wondered if there was no way to turn this HTML into PDF.
Which led to the use of html2pdf, my frontend sent me an object corresponding to her CV and I just had to format it and generate the PDF.

HTML2PDF

The Dependency

First imported via your favorite dependency manager (here maven).

What is a PDF?

What is a PDF? It’s a file format, so let’s start from the beginning, create a file (thanks captain obvious).

Fill the File

To do this, nothing is simpler than to use the HtmlConverter class and its convertToPdf method which takes as a parameter :

A String : The HTML code as a String
An OutputStream : The PDF file.

In the above example, the html variable is a StringBuilder that is built by browsing the properties of a previously populated object. Warning, tags such as are not taken into account, so how to insert css?

That simple :

Use the style property of the HTML tag

<span style=”font-weight: bold;”>
use tags and feed the content between the two by the content of a css file that you will read before

And then use the class property of the HTML tag to add your style
html.append("
")
Warning : complex file like the Bootstrap css can produce some errors in the console of your IDE, but nothing to fear, the file will be generated anyway.

pros and cons

Pro
- Easy to use.
- Well documented.
- Converting HTML to PDF is a fraction of the possibility of this library.
Cons
- Code redundancy if the object in question is already displayed on the frontend side.
- Complex CSS files can generate console errors.
- Maintenance difficulty in case of a large file.

Rock your Github profile

Erwan Le Tutour — Fri, 04 Feb 2022 07:09:50 +0000

Prerequisites

To display a personalize github profile page, you have some steps to follow

Create a new Github repository named after your username, for exemple if your Github username is GithubRockstar, your repository should be named GithubRockstar.
Make this repository public.
Add a Readme.md file in the root of this repository.
The Readme shouldn’t be empty, else you will display nothing.

Customizable content

At this point, I assume that you know how to write markdown, if no I recommend you to read this manual, else what can we add in this Readme profile page ?
Pretty much what we can already add in the readme of our different projects repositories.

badge
emote
formated text
images and gif
link

Adding badge

badges are common in Github repository, so how can we add them, simple we will use **Shield.io **it permit to build badges and then copy the code to add to your readme.
With that tool you can personalize :

the logo and it’s color
the label
the message and it’s background color

Github stats

To add stats card to your readme profile you can :

use github-readme-stats that let you put link that will transform into card like the badges latter
use github action to generate them.

Blog post

If you are active in writing blog posts, maybe you will want to add them to your readme profil page.
Mine are not generated using some action because I have linked them to the repository concerned, but you can do it using blog-post-workflow (the description of how to use it are in the readme).

The octocat

Ever wanted to have your own custom octocat to display ? Simple, you just have to go to my-octocat to build, personalise and then save it to display it later in your profile page.

For the lazy ones

If you don’t have the time to do all the above steps, know that it exist some readme generator that will do the job for you :

and many more, Google is your friend for finding them.

Spring Boot banner

Erwan Le Tutour — Thu, 03 Feb 2022 07:49:15 +0000

Usually when you start a Spring Boot application you have something like this in your console output :

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.5.5)

But did you know that you can disable it, or even create a custom one ?
No ? Yes, and it’s simple, so let’s go.

Turning banner off

If you don’t want the banner to show during the application launch you have two options :

Setting the property to off in your application.properties file

spring.main.banner-mode=off
In your main class, change the line to run the application from this

SpringApplication.run(BannerApplication.class, args);

to this

new SpringApplicationBuilder(BannerApplication.class)
        .bannerMode(Banner.Mode.*OFF*)
        .run(args);

Having a custom banner

By default Spring Boot will search a file named banner.txt in your ressources folder to use it, but your banner can also be an image (that will be transformed in ASCII), so if you want to use an image you should add a property in your application.properties file

spring.banner.image.location=**classpath:banner.png**

here I used a image of Stich as a banner, and had this output

Not very beautiful nor readable, so let’s see what I have if i use a banner.txt instead of an image.

So, I created in my ressources folder, a banner.txt file, in witch i wrote “Hello the World !!” and then started my project

Simple and efficace but, we can do better, some site provide you a banner generator that let you choose the text and the font, I have faith in your use of Google to find them, but as an example you can have something like that :

You can use place holder such as thos to add some informations in your banner.

In addition, the text can be coloured with variables such as ${AnsiColor.NAME} or ${AnsiBackground.NAME}.

JUnit parameterized tests

Erwan Le Tutour — Wed, 02 Feb 2022 07:14:48 +0000

Parameterized test?

Since JUnit4 we can now run the parameterized test, but what does that mean? It means that we can run one test multiple times with different values, great isn’t it?

How to?

Yeah that great, but how can I do that?
That simple :

Annotate your test class with @RunWith(Parameterized.class)
Create method annotated with @Parameters that returns an Iterable of Objects as test data set.
Create a constructor that takes as a parameter what is equivalent to one row of your dataset. Or create instance variable that will be equivalent as one parameter and annotate them with @Parameter(X) where X is the parameter index in a row of the dataset.
Create a test case that will use your instance variable.

Ok, but concretely can I have an example?

Exemple

Class to test

Let’s take a simple class, that take a String literal of a calcul as parameter and return the result.

Classique Junit test

In a Classique way I wrote this test class to test each one of my case

As you can see, I have one test per test case, here as my class is simple, it doesn’t have that much line, but what if my class was more complexe, it will be a lot more code, redundant isn’t it?

Parameterized

Here is the same test, but parameterized, you can see all the previous statement established in the How-to section

The runner
The dataset
The parameters
The test who use it

So with one test, I have my 5 previous test cases tested.

Thanks for your reading time, the example in this article are in Junit4, if you want an exemple using Junit5, I will write another article about it.

Generate API client with OpenApi codegen

Erwan Le Tutour — Tue, 01 Feb 2022 07:07:06 +0000

A lot of API are documented using Swagger, it’s a good thing that API are documented for us developer for understanding how they work and how to call them.
In this article, I will try my best to help you use this documentation in order to generate a client that will call those API.

What you will need

In order to follow this tutorial, you will need a REST API, so you can :

Follow those tutorial to built your API, one to documente it and then migrate to openApi
Having another API documented with openApi 2 ready

Step 1 : importe the api json documentation

The easy part of this tutorial is to import the json documentation of the api you want the first one to call an put it in your ressource folder.
In my exemple I will use my clone API and I have created a Jedi one, so in order for my clone to retrieve the jedi, i will import the jedi documentation file for then generate it’s client

Step 2 : Updating our pom.xml

To generate the client we will use the openApi codegen maven pluggin.

To do that we need to update the build part of our pom.xml and add the pluggin.

So let’s see what we have here :

the goal generate indicate us that the client will be generated during the … generate phase of our build, or can be generated using the maven command mvn generate.

The configuration will hold some option used to customized the generated client like :

the inputSpec that tell the pluggin where to find your imported file
the generatorName for the case
sourceFolder will be were my client will be generated in my ressource folder

You can add some more options, I recommend you to read the README.md of the project to have a better understanding of the possible options and choose those that applies to your case.

Step 3 : Launch a build

Now that we have implemented the pluggin usage, let’s go to clean install our project.
If all goes right you should have in your target folder, something that look like that :

As you can see, at the path described in the pluggin configuration I have my controller JediControllerApi who use ApiClient to call the jedi API and the model described in my documentation Jedi that are generated.

With that I can directly use this object in my project without having to create my own and then do some mapping.

Step 4 : exploring the generated files

If you have carefully read the step 1, in my documentation file, the server url was my localhost using port 8082, so in my ApiClient i will also have a field (basepath) that will have this value

private String basePath = “http://localhost:8082";

By default the generated client will use Okhttp to make the api call, so you may have to add some more dependencies to your pom.xml in order to run your app.

Step 5 : using the client

Now that we have gone all the way through the generation of the client, it will be best to use it don’t you think ?
Nothing really hard here, just declare your generated controller and call it to reach the second API

JediControllerApi jediControllerApi = **new **JediControllerApi();
**return **jediControllerApi.getAllJedi();

Thanks for your reading time, as previously, the code used in this tutorial is findable in this Github repository, branch openApiCodeGen.

Migration from Swagger 2 to OpenAPI 3

Erwan Le Tutour — Tue, 01 Feb 2022 07:01:25 +0000

A lot of API are documented using Swagger, it’s a good thing that API are documented four us dev for understanding how they work and how to call them.
But a lot of these API are documented using Swagger 2, now that OpenApi is released (since 2017, the actual version is the 3.1 and is available since 15/02/2021) some projects didn’t update their documentation tools, I will try in this article to help you do so.

What you will need

In order to follow this tutorial, you will need a REST API, so you can :

Follow the tutorial to built your API and the one to documente it
Clone the swagger branch of this repository
Having your own API documented using Swagger 2 ready

Step 1 : getting ride of SpringFox dependencies

When we first implemented our Swagger, we add these dependencies to have

The json generated at http://localhost:8080/v2/api-docs
The UI at http://localhost:8080/swagger-ui.html
The Bean Validation

We will not need it anymore, so you can suppress them from your pom.xml. Those 3 dependencies will be replaced by just one

With just this dependency we will have:
The json generated http://localhost:8080/v3/api-docs/
The UI page http://localhost:8080/swagger-ui.html
The bean validation

At this point, we should have some compilation problems because of some annotations due to the missing dependencies that we have replaced.
We will corrige that now.

Step 2: changing the annotations of the endpoints

In the previous tutorial, we documented our API using a configuration class

Here we have 2 choices

declaring a new configuration class
Using annotations in one of our controllers

I will give you 2 equivalent example of the previous code in OpenApi way

Configuration class

With annotations

What it will look like in the UI

The previous example will look the same in the UI page, so it’s up to you to choose what method you want to use

Step 3: changing the annotations of the endpoints

Swagger 2.0 annotation

Let’s take an example

Here is a POST method documented with classique Swagger 2 annotations

@ApiOperation : Describes an operation or typically a HTTP method against a specific path.
@ApiResponses : A wrapper to allow a list of multiple ApiResponse objects. Here I have 2 @ApiResponse to describe my 200 and 500 HTTP status return code.
I can also describe what my status will return, the 200 will respond with an objet, so I added the object class to response field.

That will render like the following picture in the UI page

Here a second example with this time a GET method

Here in addition of the previous annotations, I have added the documentation of the method parameter using @ApiParam.

With the new dependency, the annotation described are no longer the same.
So let’s see what has changed.

OpenAPI annotations

With the 2 above example who is the same method that i used previously we can now see some of the changes that was operated.

@ApiOperation *-> *@Operation, the value field become summary and notes *become *description.
@ApiResponse : the field code become responseCode and is no longer an integer but a string, also the field message become description.
The biggest change is that the response field is now an annotation. @content.
@ApiParam become @Parameter

They are other change, but since they are not used here, i recommend you to use the openAPI documentation.

Step 4: changing the annotations of the models

Swagger 2.0 annotation

So in Swagger 2 when i wanted to document an object, my class looked somewhere like this

As you can see, my classe is annoted with the @ApiModel and it’s properties with @ApiModelProperty.
*The *@ApiModelProperty allow us to add definitions such as description (value), name, data type, example values, and allowed values.

OpenAPI annotations

If you look closely at my ApiResponse with status code 200, you will see that the response is now @content, and that we gave the schema field the class that will be returned like this @Schema(implementation = MyClass.class).
With that annotation, OpenApi know which class to load, so i don’t have to annotate my class with an @ApiModel like annotation, but I still can document my property.

So, what I have done here ?
Like previously, my fields are documented, but I have used 2 differentes method for some validation (size).

I can use the bean validation annotation, or I can use the property of the Schema annotation, the result will be the same.

The position property don’t exist anymore, the fields are in the same order as the class.

Thanks for your reading time, as previously, the code used in this tutorial is findable in this Github repository, branch toOpenApi.

Monitoring your REST api with Prometheus and Grafana

Erwan Le Tutour — Tue, 01 Feb 2022 06:54:39 +0000

After having built, secured and documented our API, we will now learn how to monitor it.
To do that we will use Prometheus and Grafana :

Prometheus will serve to collect the API metrics
Grafana will display it in panel to help to visualise the metrics

What you will need

If you have followed the previous tutorials, you will only need to install docker to host our prometheus and grafana.
Else you need a running API, you can do that with these 2 options :

pull this repository branch master
create a quickstart project with Spring initializr
installing docker

Importing Grafana and Prometheus images

To add grafana and Prometheus to your docker local registry go to docker-hub to search them :

And then, pull then using the command line.

Normally you should see something like this in your docker CLI.

You can directly run Grafana in a container, but Prometheus will need further configuration.

Exporting our metrics to Prometheus

Firstly to export our API metric, we need to add some new dependencies to the pom.xml

<!-- Spring boot actuator to expose metrics endpoint -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Micormeter core dependecy  -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>
<!-- Micrometer Prometheus registry  -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

Actuators

The first dependency let us know of some usefulls information about our running application.
To read them we only need to start our application go to http://localhost:8080/actuator.

Prometheus

As you can see in the capture upside, with the third dependency, we have a prometheus section in our actuator.
If I follow the link i will see a list of values representing metrics from my application, like :

jvm information
http request status on endpoints
log event
…

Now that we expose our metrics to the /prometheus endpoint, we need to configure the prometheus server to collect them.

The configuration file

We need to configure our prometheus to collect data from our endpoint, to do that we need to overwrite the prometheus.yml file.

First we need to create a prometheus.yml file.

global:
  scrape_interval:     15s 
  evaluation_interval: 15s 

rule_files:
*# - "first_rules.yml"
# - "second_rules.yml"

*scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['127.0.0.1:9090']

  - job_name: 'spring-actuator'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['XXXXXX:8080']

Replace the XXXXXXX by your IP adresse, as prometheus will be running in a docker container, he will not know localhost.

Secondly we will create a docker file to run prometheus with the new configuration file, myApp.dockerfile

FROM prom/prometheus
ADD prometheus.yml /etc/prometheus/prometheus.yml

With that file, we specify to docker to create a copy of the prometheus image and to add our newly created prometheus.yml to the correct directory.

Now that we collect our metrics on prometheus, we can now configure our datasource in Grafana.

Configuring Grafana

login

When you access your Grafana on your container, you arrive to a login page, to pass that page you can use the default credentials admin/admin.

Configuring the datasource

In the navigation bar on the left, when you click on the gear icon, a submenu named datasource is displayed, click on it.

Here we want to add our previously configured Prometheus as the datasource.

In the list of possible datasource, select Prometheus.

On the URL input, enter your prometheus container ip adresse.
You can test your connexion, if it’s valid you can continue to the next step, if you have error, you can read the grafana documentation to find a way to connect.

Creating dashboard

Now that we have logged into Grafana, we can produce some dashboard to display our metrics

Here I have created 4 request to display the number of HTTP request to my API endpoint by status code.

Thanks for your reading time, as previously, the code used in this tutorial is findable in this Github repository, branch monitoring.

Documenting your API with Swagger 2

Erwan Le Tutour — Mon, 31 Jan 2022 13:15:43 +0000

So after having built our API and then secured it, we will now document it to allow others to use it more easily. To do that, we will implement Swagger.

What you will need

In order to follow this tutorial, you will need a REST API, so you can :

Follow the tutorial to built your API
Clone the master branch of this repository
Having your own API ready

What il will look like

I document, you document, we document

The first dependency

So, if we want to use swagger for our API, we first need to add a maven dependency

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.9.2</version>
</dependency>

The java configuration

To enable Swagger, we need to configure it, so let's create a configuration class.

As you can see, in the method apiInfo, I describe the general informations of my API :

The title
The description
The version
The termes of service (url)
The Contact to join the API owner
The licence
The licence url
The API vendor’s extension

All these informations will be displayed latter.

The JSON generated

So if I start my application and go to the http://localhost:8080/v2/api-docs, i will see a JSON representation of my documentation

As you can see, i find all the informations that I have filled in my configuration class.
But let’s be honest, a json file is good, but an IHM will be better.
So let’s implement this IHM.

The swagger-ui IHM

To enable the IHM, we don’t need to do so much work, just adding a maven dependency is enough

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.9.2</version>
</dependency>

And then, if I restart my application and go to http://localhost:8080/swagger-ui.html, I can see a beautiful (all relative) IHM that display my API information.

So now we have our swagger IHM, but there is no true documentation on it, we have our endpoint, and if we extend it we have some informations, but nothing very documented.
So let’s add our documentation.

Documenting our controller

with the previous step completed, if I expend the POST endpoint i should see something like this

So let’s add some documentation on my controller.

With

@ApiOperation : I can add a more detailed description of my endpoint (value), and specified what it consume and produce.
@ApiResponses : I describe the returns codes of my API, here the 200 and the 500.

So if i restart my application (again) I should be able to see the change

That’s better.
We have see that in my API documentation, that my endpoints are documented, but I also have a section about my models (what my API produce or consume), and these models can also be documented.
So let’s go and add some documentation on it.

Documenting our models

So I have my Clone class as my model, in here i have few properties that are not documented and it represented in my swagger like this

Except the type of my properties, I don’t have so much info on it.
To add it we will use the @ApiModel annotation on the class and the **@ApiModelProperty **annotation on properties that will allow us to add definitions such as description (value), name, data type, example values, and allowed values.

SO now my Clone class will be like this :

and in my Swagger-ui, now the model will be like this :

As you can see the mandatory field that i have described have a **.*

Testing our API with Swagger

So now that we have our swagger running and well documented, what can we do with it ?
We can test our endpoint !
Scrolling through the swagger-ui page, you should have noticed this button in each one of our endpoint.

If you click on it, it will slightly change your page so that you can write the body of the request, or edit some parameter.

Then you can execute the query against your localhost and see the result below.

Thanks for your reading time, as previously, the code used in this tutorial is findable in this Github repository, branch swagger.

Securing your rest API with SpringSecurity

Erwan Le Tutour — Mon, 31 Jan 2022 13:11:37 +0000

What we will do

After creating our API in the previous step, we will now secure it using Spring Security.
In order to do so, we need to add 2 dependencies to our pom.xml file

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-test</artifactId>
    <scope>test</scope>
</dependency>

What it will look like

Execute Order 66

The Account Entity

In order to secure our API, we will use some roles, so to achieve that, we will create an account entity that will use those roles.

The Repository

In order to know if the user who will try to use our API exists and have the role associated we also need to create the repository linked to the Account entity.

When we created the CloneRepository earlier, we didn’t need to create any method in it because all the methods we used were already implemented thanks to inheritance.
Here we will need a specific method like the one above findOneByUsername, with that one our repository will know that we search only one result that matches the String username passed on the argument. (see Spring Data JPA doc if you want to know how it works).

The controller

Now that we have created the account that will have the roles to connect to our API we can update our controller to make it accept these roles on its method.

As you can see, our method now avec the @PreAuthorize annotation that indicates the roles who can access it.

So, is my API secured now? The response is NO !
We have created the account entity and its a repository, we have upgraded our controller to indicate the roles that it will use, but we have yet to implement the security configuration.
So now let’s implement it.

The configuration

In order to make all the above code run properly, we will implement security.
To do so we will extend WebSecurityConfigurerAdapter in a configuration class.

Configuration

As you can see in the first configure method, we indicate the roles who can access the endpoint.
In the second method, we describe the service that will be used to authenticate the user.

Authentication Service

To authenticate our user we need to create a service that will implement the UserDetailsService from the Spring Security package, especially the method loadUserByUsername.

Testing our API

To test our API we need to first launch our application.
Then we can try to connect to the entry point that we created in our controller using postman or any other tool that permits you to make HTTP calls.

the examples will be the same as when we created the API, but with basic authentication.
In order to test my API, I have created 2 accounts that will be pre-loaded in the database.

So now if I try to access a datapoint with bad credentials, i will have a 401 error.

{
  "timestamp": "2021-03-08T09:45:09.332+00:00",
  "status": 401,
  "error": "Unauthorized",
  "message": "Unauthorized",
  "path": "/kamino/order66"
}

And if i try to access a datapoint when i don’t have the appropriate role, i will have a 403 error.

I have intercepted my 403 error in my exceptions handler to have something more readable than the exception stack trace.

Thanks for your reading time, as previously, the code used in this tutorial is findable in this Github repository, branch security.

Building a simple rest API with SpringBoot

Erwan Le Tutour — Mon, 31 Jan 2022 12:59:56 +0000

If you have read my previous articles, you may know that i like to use an object that symbolises human as example, so I will continue in this tutorial about building a REST API with Spring Boot, but in order to make it less scholar and more fun, I will use Star Wars reference (because i’m a geek and fan of this film franchise).
So welcome to Kamino.

What you will need

To begin, you have to choices to initialize your project :

Spring initializr
from your IDE
As we will use Spring Boot, you will need to add the following dependency to your project in order to it to work.
Spring Web : Uses Apache Tomcat as the default embedded container.
Spring Data JPA: Java Persistence API using Spring Data and Hibernate.
H2 Database: Embedded in memory database.

What il will look like

3, 2, 1 … Start

The entity

First we need to declare the object we will use in the rest of this exemple, the definition of the Clone Troopers : Clone.

In order to persist our object in the database, it will need an Id, that will be auto-generated when we will save it.

The Repository

To manipulate our objects in the database we need a repository

Our CloneRepository extends JpaRepository who extend PagingAndSortingRepository *that permit to use pagination request, who extends *CrudRepository (CRUD is an acronym to create, read, update, delete).

With ou repository, we can use method like save, findById, findAll (with or without pagination).

The controller

Now that we have our object, and the repository to save and retrieve it, we need the entry point to our actions : create, find, delete …

As you can read, even with no line of code in ou repository class, we can freely use the method inside.

So let's see what we have here :

@RestController: is to indicate that our data will be returned in the response’s body and not in a template
We have @GetMapping @PostMapping and @DeleteMapping that indicate the Http method that is linked to our method.
We have a BeanNotFound throw by our methods (we will see later how we use it).

Handling the exceptions

What is a proper way to handle exceptions, a try/catch block in every method, or to intercept them in a specific way and then use them in a uniform way?

The second method is cleaner, as we can have all our exceptions in the same place, and treat them the same way.

As you can see, our BeanNotFound is intercepted by the ExceptionHandler and then we return our exception message as a 404 error.

Testing our API

Creating a clone

As described in the controller, we need to use the HTTP POST method a pass in it’s body the information of our clone.

HTTP POST [http://localhost:8080/kamino/](http://localhost:8080/kamino/)

{
  "codeName": "CT-7567 REX",
  "type": "gunner",
  "platoon": 501
}

That will return us this response

{
  "id": 1,
  "birthPlace": "Kamino",
  "codeName": "CT-7567 REX",
  "type": "gunner",
  "platoon": 501,
  "affiliation": "Galactic Republic"
}

The Id is auto-generated, so if we create another clone, the value will be 2, then 3, and will keep incrementing.

Finding all the created clones

To find the created clones, we will call the GET “/” endpoint that will return us a list of all our created clones

HTTP GET http://localhost:8080/kamino/

that will gave us a response like this one :

[
  {
    "id": 1,
    "birthPlace": "Kamino",
    "codeName": "CT-7567 REX",
    "type": "gunner",
    "platoon": 501,
    "affiliation": "Galactic Republic"
  },
  {
    "id": 2,
    "birthPlace": "Kamino",
    "codeName": "CC-3636 WOLFFE",
    "type": "gunner",
    "platoon": 501,
    "affiliation": "Galactic Republic"
  }
]

Deleting a clone

To delete a clone in the database, we will call the delete endpoint

HTTP DELETE http://localhost:8080/kamino/1

passing 1 as a parameter, we will delete the clone that has the id : 1. So if we call again the find method we will only have one remaining clone.

{
  "id": 2,
  "birthPlace": "Kamino",
  "codeName": "CC-3636 WOLFFE",
  "type": "gunner",
  "platoon": 501,
  "affiliation": "Galactic Republic"
}

Thanks for your time, you can find all the source code in the Github repository associated to that article here.

Strategy design pattern — Java

Erwan Le Tutour — Fri, 28 Jan 2022 12:12:23 +0000

Definition of the Strategy pattern

In computer programming, the strategy pattern **(also known as the **policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

Where to use the Factory pattern

When you want the algorithm to vary independently from clients that use it.

UML example

Implementation of the strategy pattern

First, we need to declare an Interface or an Abstract class, here I used both but a single abstract class could have done the job.

what i want to achieve is that depending of the context my code will behave differently so let’s implement some strategy.

For the purpose of this tutorial, i created 2 strategies : PlusOperationStrategy and MinusOperationStrategy, both extending my abstract class.

With them being of the same supertype by inheritance, I can substitute them in the function of the needed behavior.

So now, if I want to use my strategies, and more precisely the compute method implemented in it, I need a context.

So based on the strategy passed as a parameter the context will use the compute method it.

So now, let’s see how it work

The above snippet will return this result

5
-1

Thanks for your reading time, the code used in this tutorial is findable in this Github repository.

Factory design pattern — Java

Erwan Le Tutour — Fri, 28 Jan 2022 12:09:02 +0000

Definition of the Factory pattern

In class-based programming, the **factory method pattern** is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method — either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes — rather than by calling a constructor.

Where to use the Factory pattern

When a class doesn’t know what sub-classes will be required to create
When a class wants that its sub-classes specify the objects to be created.
When the parent classes choose the creation of objects to its sub-classes.

UML example

Implementation of the Factory Pattern

We are going to create a Human abstract class and then the different periods of age that will implement it, then we will create the factory that will generate it.

The human abstract class

The implementations

Each implementation overrides the getAge() method to return a random int that will correspond to the age period.

The factory

Now we can create the factory that will generate a Human based on the given information, here we will use an enum to be sure that we don’t pass the nonexisting value to the factory

now we can generate our humans using the factory

Usage

that will give an output like the following one :

==============================
age : 8
==============================
==============================
age : 49
==============================
==============================
age : 99
==============================

Here are other **design pattern articles **you may like
7 Best Online Courses to learn Object-Oriented Design Pattern in Java
10 OOP Design Principles You Can Learn in 2021
7 Best books to learn Design Patterns for Java Programmers

DEV Community: Erwan Le Tutour

HTML to PDF — Java

Use Case

HTML2PDF

The Dependency

What is a PDF?

Fill the File

pros and cons

Pro

Cons

Rock your Github profile

Prerequisites

Customizable content

Adding badge

Github stats

Blog post

The octocat

For the lazy ones

Spring Boot banner

Turning banner off

Having a custom banner

JUnit parameterized tests

Parameterized test?

How to?

Exemple

Class to test

Classique Junit test

Parameterized

Generate API client with OpenApi codegen

What you will need

Step 1 : importe the api json documentation

Step 2 : Updating our pom.xml

Step 3 : Launch a build

Step 4 : exploring the generated files

Step 5 : using the client

Migration from Swagger 2 to OpenAPI 3

What you will need

Step 1 : getting ride of SpringFox dependencies

Step 2: changing the annotations of the endpoints

Configuration class

With annotations

What it will look like in the UI

Step 3: changing the annotations of the endpoints

Swagger 2.0 annotation

OpenAPI annotations

Step 4: changing the annotations of the models

Swagger 2.0 annotation

OpenAPI annotations

Monitoring your REST api with Prometheus and Grafana

What you will need

Importing Grafana and Prometheus images

Exporting our metrics to Prometheus

Actuators

Prometheus

The configuration file

Configuring Grafana

login

Configuring the datasource

Creating dashboard

Documenting your API with Swagger 2

What you will need

What il will look like

I document, you document, we document

The first dependency

The java configuration

The JSON generated

The swagger-ui IHM

Documenting our controller

Testing our API with Swagger

Securing your rest API with SpringSecurity

What we will do

What it will look like

Execute Order 66

The Account Entity

The Repository

The controller

The configuration

Configuration

Authentication Service

Testing our API