SPRING 3.0 MIGRATION OVERVIEW

Spring Boot 3.0 has just been released, packed with exciting new features such as advanced observability, better support for native compilation with Graal, and the ability to utilize the latest Java language features. However, for many individuals, upgrading to this latest version may appear overwhelming. The reason being, it requires the updating of many other aspects, such as the Java versions and a transition to Jakarta EE 9. Additionally, given the probability of your organization running several different dependency versions, the migration process can become even more complicated.

It is common to adopt an approach that revolves around the ideology of “if it’s not broken, why fix it?” However, it is important to note that the support for Spring Boot 2.x is scheduled to end by the end of 2023. Additionally, upgrading to the latest version of Spring Boot will provide you with access to a range of new features available across different tools. For instance, upgrading to Java 17, a prerequisite for Spring Boot 3.0, will not only grant you access to a variety of new Java language features (such as pattern matching, records, switch expressions, etc.), but it will also improve the performance of the virtual machine and garbage collector.

MAIN STEPS

Migrating to Spring Boot 3.0 necessitates a series of associated migrations and dependency updates that must be carried out before upgrading to this latest version of Spring Boot. These include:
• Updating your organization’s applications, infrastructure, and CI/CD pipeline to use Java 17. The upside to this step is that it can be done before updating any of your Spring Boot applications.
• Any pre-existing Spring applications that utilize Java EE will require an update to Jakarta EE 9. While this may seem like a simple task of moving all imports from the javax namespace to the jakarta namespace, it also requires the migration of any third-party libraries to versions that are compatible with Jakarta EE 9.

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.validation.Valid;
->
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.validation.Valid;

There are instances when we may not need to refactor package names when upgrading our software, as some dependencies such as javax.sql.DataSource already belong to JDK 17, not Jakarta EE. In these cases, it is not necessary to make any changes to the package name, as it is already consistent with the latest version of our app. It is important to note, however, that it is essential to thoroughly review and test all dependencies to ensure that they are compatible with the new version of the code.

• Lastly, depending on which version of Spring Boot your applications are being migrated from, there may be a need to make several required changes to both the application’s code and configuration when moving to Spring Boot 3.0.
It is crucial to take note of these steps, as they are all essential requirements that must be fulfilled before upgrading. Sometimes we need to just upgrade dependency version, sometimes we have to migrate to a new package. For example:

<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-ui</artifactId>
<version>1.6.11</version>
</dependency>
->
<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
<version>2.0.0</version>
</dependency>

POST MIGRATION ISSUES – COMMON EXAMPLES

#1

Now let’s look at a situation where we want to update a library used by other applications as a Maven dependency.

Parameter 0 of constructor in com.some.package.a.Class required a bean of type 'com.some.package.b.SomeExternalClass' that could not be found.

There is a good chance that exporting configuration files is the cause. Before 3.0, Spring Boot checked for the presence of a META-INF/spring.factories file within your published jar. The file should list your configuration classes under the EnableAutoConfiguration key. Now, instead of providing configuration in META-INF/spring.factories, you would do so in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.

org.springframework.boot.autoconfigure.EnableAutoConfiguration=pl.inero.commons.email.EmailServiceConfiguration
->
pl.inero.commons.email.EmailServiceConfiguration

We’llonfiguration properties for Redis have moved from spring.redis. to spring.data.redis. as redis auto-configuration requires Spring Data to be present on the classpath. Also configuration Properties for Cassandra have moved from spring.data.cassandra. to spring.cassandra..

Now let’s take some Spring Security related issue.

#2

Invalid CSRF token found for http://localhost:8080/api/test
Responding with 403 status code

When using Spring Security, it’s important to be aware of changes between different versions of the framework. For example, in Spring Security version 5, the CsrfToken is loaded by default on each request, which means that even unnecessary requests must have the HttpSession read in a typical setup. However, the default behavior of Spring Security 6 is to postpone the lookup of the CsrfToken until it is actually required.

In our particular application, the CsrfToken is required for every request, so we need to make sure that we specifically opt into the 5.8 defaults to ensure that the CsrfToken is loaded on every request, as it was in version 5. This is a necessary step to ensure that our application runs as intended and that we do not encounter any issues related to the CsrfToken during runtime.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
return http
/ ... /
.csrf(csrf -> csrf
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()))
/ ... /
}
->
@Bean
DefaultSecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
CsrfTokenRequestAttributeHandler requestHandler = new CsrfTokenRequestAttributeHandler();
requestHandler.setCsrfRequestAttributeName(null);
return http
/ ... /
.csrf((csrf) -> csrf
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
.csrfTokenRequestHandler(requestHandler)
/ ... /
}

#3

Cannot resolve method 'antMatchers()' (...)

Methods like antMatchers() (as well as mvcMathcers() and regexMatchers()) have been deprecated and removed with Spring Security 6.0 (have a look at this link if you wonder why: Deprecate trailing slash match). Overloaded method requestMatchers() was provided as a uniform mean for securing requests. It facilitates all the functionality of the configuration methods that have been removed from the API.

Also, method authorizeRequests() has been deprecated and shouldn’t be used anymore. A recommended replacement – authorizeHttpRequests() (you can find more information regarding these changes here). Here we have sample code and how it could have been changed:

http.requestMatcher(new NegatedRequestMatcher(new AntPathRequestMatcher(API_KEY_URI_MATCHER)))
.httpBasic().and()
.authorizeRequests()
.antMatchers("/ping").permitAll()
.anyRequest().authenticated();

->

http.securityMatcher(new NegatedRequestMatcher(new AntPathRequestMatcher(API_KEY_URI_MATCHER)))
.httpBasic().and()
.authorizeHttpRequests()
.requestMatchers("/ping").permitAll()
.anyRequest().authenticated();

ON CONFIGURATION PROPERTIES

When upgrading to Spring Boot 3.0, it is essential to update the configuration properties in the application.properties or application.yml files to account for any changes or removals of properties. Spring Boot provides a convenient tool called spring-boot-properties-migrator to help with this migration. By adding this module as a dependency to our project, it will migrate the properties temporarily at runtime and analyze the application’s environment to print diagnostics at startup.

To add the spring-boot-properties-migrator module to our project, we need to add the following dependency to the pom.xml file.

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-properties-migrator</artifactId>
<version>3.0.0</version>
<scope>runtime</scope>
</dependency>

This will ensure that our properties are migrated correctly and that we can benefit from any diagnostics provided by the module during startup.

As always, more tips on migration can be found in the Spring documentation. Check it out now.

In Inero Software we build digital products for digital logistics of tomorrow. We connect active aproach to analysis of business needs and combine with cutting edge technologies and AI/ML. In the blog post section you will find other articles about IT systems and more!

Artykuł Spring Boot 3.0 migration overview pochodzi z serwisu Inero Software - Software Consulting.

SchedulerFactory schedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();

public class FileDownloadJob extends QuartzJobBean {

   @Override
   protected void executeInternal(JobExecutionContext jobExecutionContext) throws JobExecutionExceptions{
       // target code of performed operations
   }
}

JobKey jobKey = JobKey.jobKey((task.getId());

JobDataMap jobData = new JobDataMap();
jobData.putAll(new HashMap<>() {{
 	  put("email", user.getEmail());
  	  put("name", user.getName());
          put("progress", task.getProgress());
}});

JobDetail jobDetail = newJob().ofType(FileDownloadJob.class)
       				.withIdentity(jobKey)
      				.setJobData(jobData)
      				.build();

Trigger trigger = newTrigger()
       .startNow()
       .build();

scheduler.scheduleJob(jobDetail, trigger);

public class FileDownloadJob extends QuartzJobBean implements InterruptableJob

@Override
public void interrupt() {
   _interrupted = true;
}

if (_interrupted) {
   break;
}

scheduler.interrupt(jobKey);

jobDataMap.put("nextJob", nextTask.getId());

Artykuł Java: Scheduling the execution of background tasks using Spring pochodzi z serwisu Inero Software - Software Consulting.

Below you may find 10 tips on how to find a good remote development team that matches your expectations, is able to easy go from vision to technical requirements, and finally develop a software product that reflects your concept and business needs.

1. Search for the right team

At the beginning, you have to choose wisely the right software dev company that can develop the product based on your concept. There are many ways and things you can do to verify if the company you find is appropriate for your needs. You can define the number of criteria and prepare questions that can help you to distinguish between teams which are potentially good for you and those which are not. Many basic checkings that are always carried out when this issue appears include:

• portfolio of the company
• opinions about the company from Google, Clutch etc.
• does the profile and field of expertise of software company matches the vision of your product
• technology stack etc.
• experience in developing similar solutions
• expert knowledge
• pricing
• dev team availability
• language & communication level
• QA (quality assurance) policy
• etc…

However, the most important thing that is often not taken under consideration is the good understanding of your business model. Before you start the cooperation, you have to make sure that the partner you want to make business with, understands your idea and analyzes your feedback. Check if the team is involved in requirements analysis and is actively searching for solutions on how to make your product better. If the dev team asks difficult questions and addresses issues that you were not aware of before the conversation, this is the good sign that it may be a valuable partner for your future cooperation. Good dev team should also share knowledge and expertise with you as a potential future partner. It should provide you with tips on how to talk with other entities and which issues should be raised in your case.

2. Contact

Don’t hesitate to get in touch with the people from SH. Here we are people too, we really want to discuss about your vision, and really want to bring it to business reality. Remember, that software companies will not charge you for initial requirements analysis or just human-2-human conversation about your idea. Actually, it may be very important if IT experts can verify your idea from technical point of view for free! You can get technical feedback and improve the concept using the expert knowledge.

3. You don’t need to be technical expert (but you must be a visioner)

Many potential clients hesitate to make the first contact with SH representatives, wondering if they have enough knowledge and experience to describe what they do or want to do, or how their vision may be translated into a set of technical requirements. Remember that you don’t need to know in detail the engineering jargon or know the technical names of solutions that you wish to be applied in your vision of the product you want to build. It is up to project manager or SH team to ask you the right questions and make sure that both sides of the conversation understand each other. Good project manager will try to get as many as possible answers to questions concerning your vision because he wants to truly understand your concept and transfer it to technical language.

Many potential clients hesitate to make the first contact with SH representatives, wondering if they have enough knowledge and experience to describe what they do or want to do, or how their vision may be translated into a set of technical requirements. Remember that you don’t need to know in detail the engineering jargon or know the technical names of solutions that you wish to be applied in your vision of the product you want to build. It is up to project manager or SH team to ask you the right questions and make sure that both sides of the conversation understand each other. Good project manager will try to get as many as possible answers to questions concerning your vision because he wants to truly understand your concept and transfer it to technical language.

4. Use issue trackers and communications tools

Software development is a process that relies not only on engineering work but also on clear and efficient communication between project participants. If you assume to cooperate with your software vendor for longer period of time it is worth to consider using more convenient and matched communication tools than e-mail, Skype or phone calls. Each SH usually defines their own set of communication tools starting form e-mail and Skype, but as your project becomes more involving and complex it is worth to switch into issue tracking tools that allow you to provide feedback to your dev team members more efficiently. These are slack communicators or issue trackers like JIRA or GitLab.

Remember that you should not be charged for using communication tools, but you should expect that your project runs smoother and the work is more effective.

5. So…, how much will it cost?

Software development, especially when developing innovative products is a complicated process. It often consists of visions, conversations, mind storms, tests, setting up different variants and from time to time unmatched ideas. Once you choose your SH to develop your product, the negotiations about the costs will start. Charges for software development are individual for every company but what you need to know is that generally there are two models of how your financial cooperation may look like, these bare:

• Fixed price (FP) model is when before you start your cooperation with vendor you determine the total sum of the contract and the schedule of the work needed for your product development.
• Men & Material (M&M) which is much more flexible model when both sides of cooperation agree to fixed charge for one working hour of software development. For each period (1 week – 1 month) you should receive the report from your software vendor that contains the detailed cost calculation on working hours your dev team has spent on developing your product. Usually, invoicing is performed in month periods. That allows you to routinely track the costs of your project and keep your financing predictable.

Many clients and investors choose FP over MM because they want to estimate the exact budget of the project before the project kick-off. From obvious reasons that is very reasonable approach, especially when you want to know the maximum cost of your project and to make sure that you don’t exceed the financial limits .However, remember that it has significant drawbacks. Firstly, when you look at this from SH point of view, you need to know that when the fixed price model is used, your software vendor ensures that dev works will not exceed internal costs of the project. In this way, SH shifts the risk of unpredicted costs and additional work to your budget at the very beginning of your cooperation. Secondly, once the fixed price budget is settled, additional changes to your concept need to be discussed every time they appear, including financial revision of the budget. That usually slows down the whole process and can lead to timeline violation.

Fixed price are often more expensive for the client as SH need to set up additional unpredictable cost margin that client is being charged for. M&M model is much more flexible – all project participants  may continuously observe the costs and match the predicted amount of future work to fit the budget.

Consider what type of financial cooperation is suitable for you. You can also propose a hybrid model and divide all your work to stages (milestones). First milestone(s) of the project can be realized according to Fixed Price model. Once you get to know your team better and your cooperation runs smoother, you may turn into MM which is much more flexible and efficient in longer period.

6. Listen to suggestions, let the dev team to decide

Once you have established the schedule and budget of your project, be prepared for improvements and options that your dev team may propose. During the project development the new ideas come along and the obstacles arise on both sides of the partnership. This may lead to some changes in prior arrangements.  If you have trust in expertise of your team, try to be flexible in this area. Carefully analyze all suggestions and provide detail feedback on your decision.

Remember that good understanding between partners during development process is crucial for overall success!

7.  Routinely monitor the improvement and provide a feedback

This is very important part of the development process. In most of the cases today, your software vendor will work on your product using the agile methodology. This is not a place to discuss how the agile methodology works, but the most important thing is that you should be provided with the first version of the software product in 1-4 week period from the beginning of your cooperation. Next, the revised versions of the software product should be provided every 1-2 weeks. Your job is to verify if the product matches your vision and arrangements. Every time provide the feedback to your dev team and precisely tell which things are going in good directions and which need to be corrected. Remember that the precise feedback significantly improves the performance of your cooperation, reduces the costs and helps to maintain the schedule of the project.

8. Your success is the dev team’s success

Each stage plays a vital part in building a high-functioning team. Dev team you choose should be motivated to achieve the success of the project because once you succeed it is also a proof that your dev team achieves their goals and provides high quality services. Don’t hesitate to communicate with the team and give information precising which parts of the project are satisfying and which need to be improved. Remember, the dev team also wants you to succeed and achieve the specified business goals.

9. Clean and reusable code

Ok, here is a little more technical thing you should consider, preferably at the very beginning of the cooperation. Know that you don’t have to tie to your vendor during the whole product lifetime, although in many cases this is the best option. It is worth to assume that many things happen in life that can unexpectedly disrupt your cooperation with your dev team. The company may got bankrupt, You may have cash flow problem, the change of the business model may prevent your further cooperation – these things just simply sometimes happen. In order not to waste the investment you have already made to your product development, it is very, very, very important for you to make sure that all the work you paid for remains at your hands. Make sure you get access to so called source codes repository, so in case of any catastrophe, other vendors may look back to your project and work on it further.

Ensure yourself an access to GIT repository of your product. After a few weeks/months of cooperation, hire an external expert that can analyze the code of your product and give his feedback to your vendor. This will allow you to maintain an external control over the quality of your product. You may repeat this procedure every a few weeks. Also, make sure that your vendor follows the suggestions of your expert.

10. Forgive minor faults -> require feedback -> give up cooperation

Many business experts say that kicking off the project is the easiest part in developing new products. Once your budget is accepted, business concept is ready, you start to search for software vendor, when you find it, make the agreement, and kick off. However, closing projects and admitting to defeat is that what is most difficult. Every dev team, even the most experienced and motivated ones, make mistakes from time to time. Experienced dev teams have internal processes of software quality assurance (QA) that consist of internal requirements analysis, feedback analysis procedures, built-in software testing procedures and so on. However, problems and delays sometimes appear – that is the nature of the software development. Once it happens, it is important for you to inform your software vendor about this situation. What is more important is to know how your dev team reacts to your suggestions. Will it introduce the improvements, repair the software errors in assumed time schedule? – this is what is the most important in this case. If such a situation repeats, despite your best will, sometimes the best thing you can do is to finish cooperation and find a new software vendor.

Verify if your dev team analyzes your feedback. You may check it in the beginning of the cooperation, no necessarily when significant problems appear. You may introduce some small changes in prior arrangements, make minor shift in technical concepts – see if your suggestions are implemented during your cooperation.

Summary

Hiring remote teams of developers allows to reduce the cost of software development maintaining the schedule and the reasonable project costs at the same time. In Central Europe, number of software companies provide efficient, scalable and high-quality software services in reasonable prices. Using remote software development services can significantly reduce the costs of development of innovative concepts. Following the tips above will not make your concept 100% successful but certainly can help you to start a good and fruitful cooperation.

Inero Software provides knowledge and expertise on how to successfully use cutting edge technologies and data to shape corporate digital products of the future.

In the blog post section you will find other articles about IT systems and more!

Artykuł 10 Things You Should Know when Working with Remote Dev Teams pochodzi z serwisu Inero Software - Software Consulting.