DEV Community: Aleksandr

Be careful when using @Configuration classes with @EnableWebMvc in Spring Boot

Aleksandr — Wed, 26 Apr 2023 08:21:43 +0000

Situation

Recently, we have been faced with a strange issue after adding a configuration class to our Spring Boot application. Unfortunately, the logs didn't provide any valuable information, becuause we didn't use the bean in our new configuration class which mention in logs:

Parameter 1 of constructor in com.xyz.spring.starter.web.filter.FilterAutoConfiguration required a bean of type 'org.springframework.web.filter.RequestContextFilter' that could not be found.
Action:
Consider defining a bean of type 'org.springframework.web.filter.RequestContextFilter' in your configuration

And our new configuration class looked like this:

@Configuration
@EnableWebMvc
public class WebConfiguration implements WebMvcConfigurer {
    // some simple logic
}

After playing with the configuration, we found out that using the @EnableWebMvc annotation breaks our project. So, let's go deeper into the Spring configuration to understand why this is happening.

What is the @Configuration annotation?

The Spring Framework documentation says: the @Configuration annotation allows us to use annotations for dependency injection. This annotation tels Spring that a class has some methods which create beans that can be used in the application. When the Spring container detects this annotation, it process this class and create these beans.

Just an example of using the @Configuration annotation:

@Configuration
public class AppConfig {

    @Bean
    public MyBean myBean() {
        // instantiate, configure and return bean ...
    }
}

What is the @EnableWebMvc annotation?

The official documentation says:
Adding this annotation to an @Configuration class imports the Spring MVC configuration from WebMvcConfigurationSupport

@Configuration
@EnableWebMvc
@ComponentScan(basePackageClasses = MyConfiguration.class)
public class MyConfiguration {
}

To customize the imported configuration, implement the interface WebMvcConfigurer and override individual methods, e.g.:

@Configuration
@EnableWebMvc
@ComponentScan(basePackageClasses = MyConfiguration.class)
public class MyConfiguration implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry formatterRegistry) {
        formatterRegistry.addConverter(new MyConverter());
    }

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        converters.add(new MyHttpMessageConverter());
    }

}

And there is some very interresting point:

Note: only one @Configuration class may have the @EnableWebMvc annotation to import the Spring Web MVC configuration. There can however be multiple @Configuration classes implementing WebMvcConfigurer in order to customize the provided configuration.

In a nutshell

We can have ONLY ONE @Configuration class which annotated with the @EnableWebMvc annotation!
If we need more - we have to implement WebMvcConfigurer.

Keep in mind that this from the Spring Framework Documentation, not from Spring Boot!

What is Spring MVC Auto-configuration?

The Spring Boot Documentation says:

Spring Boot provides auto-configuration for Spring MVC that works well with most applications.

The auto-configuration adds the following features on top of Spring’s defaults:

Inclusion of ContentNegotiatingViewResolver and BeanNameViewResolver beans.
Support for serving static resources, including support for WebJars.
Automatic registration of Converter, GenericConverter, and Formatter beans.
Support for HttpMessageConverters.
Automatic registration of MessageCodesResolver.
Static index.html support.
Automatic use of a ConfigurableWebBindingInitializer bean.

If you want to keep those Spring Boot MVC customizations and make more MVC customizations (interceptors, formatters, view controllers, and other features), you can add your own @Configuration class of type WebMvcConfigurer but without @EnableWebMvc.

If you want to take complete control of Spring MVC, you can add your own @Configuration annotated with @EnableWebMvc, or alternatively add your own @Configuration-annotated DelegatingWebMvcConfiguration as described in the Javadoc of @EnableWebMvc.

In a nutshell

You can create your own @Configuration which should implement WebMvcConfigurer. But, do not include the @EnableWebMvc annotation in this class.
You can use @Configuration class with the @EnableWebMvc annotation but you have to take complete control of Spring MVC and customize every aspect of its configuration and be aware that it can cause conflicts with Spring Boot's auto-configuration and make it harder to configure your application correctly.

What does the Internet say?

Baeldung mention in the section Migrate a Spring Web Application that:

When we use spring-boot-starter-web dependency, Spring Boot automatically sets up a DispatcherServlet bean and adds the @EnableWebMvc annotation to the main Application class.
If we use the @EnableWebMvc annotation in a @Configuration class, it will disable Spring Boot's auto-configuration for MVC.

Some guy from Quora:

Spring Boot doesn’t mix well with the standard Spring MVC @EnableWebMvc. What happens when you add the annotation is that spring boot auto-configuration is disabled.

Don’t use @EnableWebMvc in spring boot, just include spring-web as a maven/gradle dependency and it will be auto-configured.

Comments from Stackoverflow

Normally you would add @EnableWebMvc for a Spring MVC app, but Spring Boot adds it automatically when it sees spring-webmvc on the classpath. This flags the application as a web application and activates key behaviors such as setting up a DispatcherServlet.

It is important to remember that 3rd point. Do not annotate any @Configuration classes with @EnableWebMvc. Otherwise, Spring MVC will load and use its own serialization/deserialization configuration, ignoring your Spring Boot config.

What you can do?

Avoid using @EnableWebMvc in spring boot, just use spring-boot-starter-web dependency and it will be auto-configured. If you need to use @EnableWebMvc annotation in a @Configuration be aware of the consequences.

References:

Follow my telegram channel

Using variables in Bazel

Aleksandr — Thu, 16 Feb 2023 16:20:16 +0000

Bazel is a free and open-source build and test tool developed by Google. Bazel uses a declarative language (Starlark) to describe the build and test steps.

This simple guide shows how to use variables in Bazel. This can be simple done in 3 steps.

We'll use an fictional example of setting Java 17 as the default version of the project to show you how to use variables in Bazel.

1: Define the Variable in a .bzl File

In this example we define the Variable in rules/jdk/compatibility.bzl

JDK17_UPWARDS = select({
    "@nasa_atlantis//rules/jdk:jdk11": ["@platforms//:incompatible"],
    "@nasa_atlantis//rules/jdk:jdk8": ["@platforms//:incompatible"],
    "//conditions:default": [],
})

We use the select function to choose the suitable value for the JDK17_UPWARDS variable based on the current platform. In the example, we use Java 17 upwards if the platform supports it, or an empty list otherwise.

2: Import the Variable in your BUILD File

We use the load function to load specific Bazel file and import the variable from it. So, to do this we just add the line below to the BUILD file:

load("//rules/jdk:compatibility.bzl", "JDK17_UPWARDS")

It loads the compatibility.bzl file and imports the JDK17_UPWARDS variable.

3: Use the Variable

Just use the variable in your BUILD file:

java_library(
    name = "nasa_atlantis-web",
    srcs = glob(["src/main/java/**/*.java"]),
    resources = glob(["src/main/resources/**/*"]),
    tags = [
        "maven_coordinates=com.nasa.spring:nasa_atlantis-web:{nasa-project}",
    ],
    target_compatible_with = JDK17_UPWARDS,
    visibility = ["//visibility:public"],
    deps = [
        "//nasa-core/nasa-events:nasa-events-sb3",
        "//libs/b-spring/nasa_atlantis-core",
        "//libs/nasa-tracing:nasa-tracing-sb3",
        "@maven_spring//:jakarta_servlet_jakarta_servlet_api",
        "@maven_spring//:org_slf4j_slf4j_api",
        "@maven_spring//:org_springframework_boot_spring_boot",
        "@maven_spring//:org_springframework_boot_spring_boot_autoconfigure",
        "@maven_spring//:org_springframework_boot_spring_boot_starter",
        "@maven_spring//:org_springframework_boot_spring_boot_starter_web",
        "@maven_spring//:org_springframework_spring_beans",
        "@maven_spring//:org_springframework_spring_context",
        "@maven_spring//:org_springframework_spring_core",
    ],
)

In our example, we use the JDK17_UPWARDS variable in the java_library rule as the attribute named target_compatible_with. This attribute specifies the versions of the Java language that the target is compatible with.

ERROR: name is not defined

You could have the issue below:

ERROR: /builds/platform/nasa/libs/nasa_atlantis-web/BUILD:22:30: name 'JDK17_UPWARDS' is not defined

The reason is likely because you forgot to import the variable in your BUILD file or the path is wrong. For example you use

load("///rules/jdk:compatibility.bzl", "JDK17_UPWARDS")

instead of

load("//rules/jdk:compatibility.bzl", "JDK17_UPWARDS")

Thats it.

Follow me in the group in telegram

My blog

SAP Hybris code review checklist

Aleksandr — Sat, 10 Jul 2021 13:30:21 +0000

General

Because the code should be fully extensible and easy to test, the reviewed code should not contain:

final methods/classes (except low-level platform features)
private methods
static methods
Utility classes should have only static methods and with very simple functionality.

*-items.xml

All Item Types which are extending GenericItem should have a deployment table.
All many-to-many relations should have a deployment table.
Deployment type codes must be greater than 10000.
Check that more abstract types are defined more to the beginning of the items.xml and more concrete types are more to the end.
Item type names must be started with an uppercase letter.
Item type names should not be started with Generated
Attribute names should be started with a lowercase letter.
Item type must have at least one unique attribute.
The Item type assignment must be described in the description tag.
Mandatory attributes (optional="false") should have either initial value defined.
Boolean attributes must be defined (because they could store null/true/false).
Relations that have cardinality='many' should not have option ordered='true' unless absolutely necessary.
CatalogVersion attributes must be unique for Catalog aware types.
Unique attributes should have database indexes.
Check whether the attribute needs to be localized.
Check those attribute definitions are not changed.
Check that deployment code or table names are not changed.

ImpEx

There is no mixing headers
There is INSERT_UPDATE rather than INSERT in Large, One-hit Imports
Many-to-many Relations are imported separately
Essential data impexes should only contain must needed data

Service and DAO

Name of the interfaces of services should be the related domain concept with Service on the end.
The interfaces of services should be located in the root package or in a subpackage named after the domain concept if appropriate (example: de.hybris.platform.catalog.CatalogService)
Services should not contain Flexible search queries inside business logic
The names of interfaces for DAO should be ended with DAO
DAO interfaces should be located in a package daos underneath the package of the service interface. (example: de.hybris.platform.catalog.daos.CatalogDao, de.hybris.platform.catalog.daos.impl.DefaultCatalogDao)
DAO methods should be named as findByXXXX where XXXX lists the parameters for the method
DAO/Service should not return null
DAO should return an empty list if nothing is found
DAO should use FlexibleSearchService.searchUnique() when searching for a single item
DAO should use pagination for potentially large queries to prevent performance issues
Services method should be named with the following pattern: getFor(). For example:

ProductModel getProductForCode(String code);
List<ProductModel> getProductsForCategory(CategoryModel category);
List<ProductModel> getOnlineProductsForBrand(BrandModel brand);

If more than one is found for a single result, it should throw AmbiguousIdentifierException
If none is found, it should throws UnknownIdentifierException
It is useful to use a parameter object instead of a long list of method parameters.
Instead of IllegalArgumentException use ServicesUtil.validateParameterNotNull,or analogs to check if an input parameter was provided.

Testing

Each class should have a related test class (including web classes) in the same package as the class it is testing but under the testsrc folder.
All public methods should be covered by unit tests.
Happy path scenario should be covered
All exception scenarios should be covered
Basic edge cases should be covered
Tests should not depend on other tests
Tests should roll back their transaction or clean up after themselves completely
Tests should be responsible for inserting the data they require

Misc

Existed properties should not be changed
Properties should be documented
Listener classes should not contain any significant business logic inside.
DTO beans should be defined in beans.xml files instead of java classes.
Controllers should use Facades, not Services and Daos

Created based on official documentation

Follow me on my tech blog and telegram

MACHathon - what it was for me?

Aleksandr — Tue, 11 May 2021 07:24:52 +0000

I was looking at the console and I didn’t understand what’s wrong. That was my first time when I use Vue Storefront, I was recognized that I’ve lost the thread. I don’t understand how to fix it and how it works. Sad thoughts, but it was a chance to learn something new. Yup, I was finding something positive at this moment. I have limited time and it should work properly otherwise we will fail.

A month before, on a frosty December evening, I got an email from my resource manager. He asked me to volunteer in hackathon with some strange name - MACHathon. I did little research. The organizer of MACHathon is The MACH Alliance. The Alliance was formed in June 2020 as a non-profit co-operation to introduce a new, open, and best-of-breed enterprise technology ecosystem. Founded by commercetools, Contentstack, and EPAM Systems.

I’ve heard about commercetools and it was an opportunity for me to try new things, but I’m waiting for a new project on my work and I was doubtful that I can successfully engage hackathon. I answered that I think about it. The theme of the hackathon was - Getting Unstuck. That means MACHathon should show up new ideas on how to help people get virtually un-stuck. I spent my New Year holidays finding the idea, but I didn’t find anything valuable. All my ideas looked banal or useless, so I stopped my research.

A few weeks later I suddenly was invited to the internal meeting there I found out that I was participating in MACHathon and during this meeting, a few teams were built and I was added to one of them. I became the fourth on the team. In addition to me in the team were another two backend developers - Andrey and Artem, and the head of the team was Olesia - experienced team lead. Our team contained only backend developers and we start to realize that we can potential problems building some beautiful fronted for our solution.

We were a bit confused. We didn’t know what we had to develop, we had to find out the idea quickly and send a request to participate MACHathon. It should be something simple to implement, usefull, and related to the theme. After a quick brainstorm session, we decided to develop a telegram bot that should help out senior people with buying groceries. It didn’t sound like rocket science, was simple and to be honest a little bit boring. First, we didn’t decide what frontend we have to use, then after some research, I found out that vue stroefront is a possible choice for this solution and others were accepted that.

We were starting our work. I was starting by bootstrapping and investigating a simple internet shop built by vue storefront and try to integrate it into commercetools. Andrey simply builds the backend part for several evenings. Luckily he was into developing telegram bots and it didn’t something extremely new for him. When we had problems connect the parts of our work. In the middle of this Artem was left us for few days - he had some urgent personal matters and couldn’t engage hackathon.

It was a week of a mess, stress, and doubts. We had no hope to build something expressive, no, we refused any improvements, just want to implement the core idea of the application. At the end of the week, we had an app deployed on Heroku. We could buy groceries using our app (without placing real orders of course). Our team leader finished some paperwork, I edited the video for the presentation and we forget about MACHathon for a while. After few days we recognized that we won the category The Relevance Award.

What I’ve learned and what I’ve got.

-I got a jolt
-I’ve tried to use cut edge technologies and I want to use them again
-MACHathon has given me confidence in my business
-I have been confirmed in the opinion that for hackathons, some raw solution is better than a non-working but with fantastic perspectives one.
-I got branded stuff from The MACH Alliance))

Our project on devpost:
https://devpost.com/software/shopping-helper-bot

MACHaton winners:
https://machalliance.org/insights/machathon-2021-winners-solutions-for-getting-unstuck-

Follow me in the group in telegram

Original post http://enterprise-developer.com/2021/04/16/MACHaton-what-it-was-for-me/

SAP Commerce (Hybris) interview questions with answers - Part 1 - Data Model.

Aleksandr — Thu, 24 Dec 2020 07:52:41 +0000

When do you need to use a deployment table?

All items that don't have a deployment table are stored in the genericitems table. It makes the genericitems table extremely large. This makes the database work inefficiently causing performance issues.
Need to define a deployment table for all item types that extend GenericItem except abstract item type.

When you can’t use a deployment table?

When Item Types already has a deployment inherited from a supertype. Technically it's possible but is not recommended because you will get performance issues because the supertype requires a UNION clause with a new table.

What deployment type codes can you use?



<itemtype code="UrlPolicy">
    <deployment table="UrlPolicy" typecode="18703"/>
    <attributes>
        <attribute qualifier="symbolsToReplaceRegex" type="java.lang.String">
            <persistence type="property"/>
            <modifiers read="true" write="true"/>
            <description>Some attribute</description>
        </attribute>
        ....
    </attributes>
</itemtype>

If you don't want to have problems in the future use type codes larger than 10000. Because the Hybris platform uses type codes from 0 to 10000.

What types of relations are required a deployment table?

If a many-to-many relation does not have a deployment table, it's data stores in the links table along with the data from all the other many-to-many relations that don't have a deployment table. Of course, you will get serious performance problems.

How many values can a boolean attribute store? Should you define it?

A Boolean attribute can store 3 values - true, false, null. So, you need to define a default value for the Boolean attribute if you want to avoid problems with NullPointerExceptions.



// Potential NPE

if (product.isSpecial()){

    someService.doSomething();

}

What are the requirements for item types names and attributes?

Item type Names should start with an uppercase letter
Item type attributes should start with a lowercase letter.
qualifier names should start with a lowercase letter.
Don't start Item type names with Generated, for example, GeneratedUserQuery - it reserved for Hybris abstract classes.

Should we use a relation that has cardinality='many' with attribute ordered=true, or it is a bad practice?

An option ordered='true' on any side of a relation that has cardinality='many' has a significant impact on performance when reading and writing from the database. Hybris build very complex queries to provide a defined order to the items that are much more complex and expensive than an unordered query.

What type of collection recommended to use for a relation that has cardinality='many'?

You have to use collectiontype='set' on any side of a relation that has cardinality='many' where items must not appear in that relation multiple times.

Should CatalogVersion attributes be unique for Catalog aware types?

Yes. Because the CatalogVersion attribute forms part of the unique key for Catalog Synchronization. Otherwise, you'll spend Friday night debugging.

Do we need to define database indexes for the unique attributes of type? Will this help us avoid duplicates?

The only database can guarantee no duplicates. The validation of the unique attributes in the Service Layer cannot entirely guarantee that there won't be duplicate records in the database.
So, you have to define database indexes for the unique attributes of the type.

What’s wrong with having a catalog aware type on the “many side” of a one-to-many relation?

You'll get an issue when synchronizing. The reference to the Catalog aware type will be transferred from the Staged to the Online version. The Staged version will no longer have a reference.

When do we need to have unique attributes for all types?

Always. All types should have unique attributes. This allows avoid duplicates and ensure import/export by IMPEX.

When do we need to use unoptimized attributes?

Never. Option dontOptimize="true" allows storing the data for this type in a secondary table defined by the propertytable attribute of the deployment or the props table if no propertytable is defined. hybris builds complex and expensive queries to handle it.

When do we have to create a new sub-type and when have we not?

We should extend the existing type when:

Need to add a new attribute for all instances We should create a new sub-type when:
Need to add a new attribute for specific instances
Need to redeclare an existing attribute (for example change mandatory to optional)

What should we do with unnecessary indexes?

We should remove unnecessary indexes. Indexes should only exist for attributes used in flexible searches. Hybris creates a significant number of database indexes that many projects never use and those indexes slow down the writing to the database.

How often do we need to use collections in items.xml?

Collection types can cause truncation issues, so we have to use relations instead.

Can we change attribute definitions?

Sure, but the modification of an attribute qualifier has serious consequences on a system update.
A change of upper/lower spelling will change the signature of generated getters/setters, so it will cause API incompatibilities.
A change of spelling is the same as removing the attribute from items.xml and defining a new one with a different name. The old data is not accessible anymore by generated API.
A change of type. If the database does not support changing the type, changing the attribute type will not change the database schema. Nevertheless, the generated API will be changed, resulting in incompatibilities and a high probability of exceptions at runtime.
The modification of attribute type in redeclaration mode can throw a build error in case of incompatible type hierarchy (for example type of attribute was from String to Long).
Modification of columntype (subtag of persistence type) will succeed if the type is compatible on the database level, otherwise, no effect happens.
With the modification of attribute modifiers, you could get API incompatibilities due to the read and write flag influences code generation.
All other modifier modifications will cause different behavior which can be serious too and must be checked in detail. (for example: adding a unique flag can cause inconsistent data).

Can we change deployment code or table names?

Changing deployment code has fatal consequences. If you change the table name, you get a new table, and you lose access to the old data. It's because the typecode specified in a deployment tag forms part of the PK of the items inside the database. It helps find items very quickly by their PK because the typecode points directly to the correct database table. If you change a typecode for a table then all old items inside the table will not be found anymore and are lost with it.

Can we change a type declaration?

You should not change a type declaration because modifying the values of an existing itemtype tag will result in API incompatibilities between the two versions. This breaks backward compatibility and makes upgrades harder.

How can we improve the performance of large impex import?

You can define a database index on the lookup value of reference types for using it in IMPEX-import for example.

Follow me on my tech blog and telegram