Errong Leng

Map-based Implementations Deprecated: Overriding getDataSource in Spring Boot's DefaultBatchConfiguration

By Errong Leng – 24 May 2024 – View online →

With Spring Batch 5.0, significant changes have been made regarding job repository and explorer configurations. The Map-based job repository/explorer implementations were deprecated in version 4 and completely removed in version 5. This necessitates customizing the default batch configuration to use a Jdbc-based implementation. Additionally, Spring Batch 5.0 mandates using the Jdbc-based JobRepository, and customizing the data source configuration can help keep batch job-related data separate from your production database. Here’s how you can override the getDataSource method in DefaultBatchConfiguration to achieve this.

Step-by-Step Guide

Create a Custom Batch Configuration Class: Extend DefaultBatchConfiguration and override the getDataSource method in your custom configuration class.
Define the DataSource Bean: Define a DataSource bean within your custom configuration class or another central configuration class.

Here's an example:

import org.springframework.batch.core.configuration.annotation.DefaultBatchConfiguration;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import javax.sql.DataSource;
import org.springframework.boot.jdbc.DataSourceBuilder;
import org.springframework.batch.core.initializer.BatchDataSourceScriptDatabaseInitializer;
import org.springframework.batch.core.configuration.BatchProperties;
import org.springframework.jdbc.datasource.init.DatabaseInitializationMode;

@Configuration
public class CustomBatchConfiguration extends DefaultBatchConfiguration {

    @Override
    public DataSource getDataSource() {
        return customBatchDataSource();
    }

    private DataSource customBatchDataSource() {
        DataSource dataSource = DataSourceBuilder.create()
                .url("jdbc:h2:mem:batchdb;DB_CLOSE_DELAY=-1")
                .username("sa")
                .password("")
                .driverClassName("org.h2.Driver")
                .build();

        // Initialize batch datasource script
        BatchProperties.Jdbc jdbc = new BatchProperties.Jdbc();
        jdbc.setInitializeSchema(DatabaseInitializationMode.ALWAYS);
        new BatchDataSourceScriptDatabaseInitializer(dataSource, jdbc)
                .initializeDatabase();

        return dataSource;
    }
}

In this example:

CustomBatchConfiguration extends DefaultBatchConfiguration.
The getDataSource method is overridden to return a custom DataSource for batch jobs.
customBatchDataSource method configures the data source properties, using H2 in-memory database.
The batch datasource script is initialized to ensure that the necessary batch job tables are created.

Ensure Configuration is Picked Up by Spring Boot: Make sure your custom configuration class is in a package scanned by Spring Boot. If not, use @ComponentScan on your main application class or another configuration class.

Job Repository/Explorer Configuration Updates

Map-based Implementations Deprecated: The Map-based job repository/explorer implementations were deprecated in version 4 and completely removed in version 5.
Jdbc-based Implementation: In Spring Batch 5.0, the Jdbc-based JobRepository is the only supported implementation. The @EnableBatchProcessing annotation will configure a Jdbc-based JobRepository, which requires a DataSource bean in the application context.
Using In-Memory Database for Batch Jobs: If you do not want batch job-related tables created in your production database, you can configure the batch job repository to use an embedded database like H2. This way, batch job metadata is stored in the in-memory database while your production data remains in your primary database (e.g., Oracle, Microsoft SQL Server, MySQL).

For more details, refer to the Spring Batch Migration Guide.

By following these steps, you can effectively customize the data source configuration for your Spring Batch jobs in a Spring Boot application while adhering to the latest updates in Spring Batch 5.0 and maintaining separation between batch job metadata and production data.

How to Generate an .aab File in a React Native Project for Google Play Console

Post, Code and Quiet Time.

How to Generate an .aab File in a React Native Project for Google Play Console

By Errong Leng – 22 May 2024 – View online →

Photo by Emilio Garcia / Unsplash

When developing a React Native app and preparing it for release on the Google Play Console, it's essential to generate the correct file format. While APK files are commonly used, Google Play Console imposes a 100MB size limit on APKs. If your app exceeds this limit, you'll need to generate an Android App Bundle (.aab) instead. Here's a comprehensive guide on how to generate an .aab file for your React Native project.

Why Use .aab Instead of .apk?

Size Limitation: Google Play Console allows APK files up to 100MB. If your app exceeds this size, you must use an .aab file, which supports larger apps.
Optimized Delivery: .aab files enable Google Play's Dynamic Delivery, optimizing app delivery to users based on their device configuration.

Steps to Generate an .aab File

1. Open Your Terminal

First, open a terminal or command prompt.

2. Navigate to the Android Directory

Change your directory to your project's Android folder:

cd path/to/your/project/android

3. Run the Gradle Bundle Command

Execute the Gradle command to build the app bundle in release mode:

./gradlew bundleRelease

On Windows, use:

gradlew.bat bundleRelease

4. Locate the .aab File

After the build process completes, find the generated .aab file in the following directory:

path/to/your/project/android/app/build/outputs/bundle/release/app-release.aab

Updating Version Code and Version Name

Before generating the bundle, update the version code and version name in your project to ensure the new release is accepted by the Google Play Console.

1. Open `build.gradle` (App Module)

Navigate to android/app/build.gradle.

2. Update `versionCode` and `versionName`

In the defaultConfig block, increment the versionCode and update the versionName as needed:

android {      ...      defaultConfig {          applicationId "com.example.myapp"          minSdkVersion 16          targetSdkVersion 30          versionCode 2          versionName "1.1"          ...      }  }

Summary

To generate an .aab file for your React Native project:

Open terminal and navigate to the android directory.
Run the Gradle command:

On Unix-based systems: ./gradlew bundleRelease
On Windows: gradlew.bat bundleRelease

Update versionCode and versionName in android/app/build.gradle if necessary.
Locate the .aab file in android/app/build/outputs/bundle/release/.

Important Note

Remember, if your APK file exceeds 100MB, Google Play Console will not accept it. Instead, you must generate and upload an .aab file for your release. This not only allows for larger app sizes but also enables optimized app delivery through Google Play's Dynamic Delivery.

By following these steps, you can ensure your React Native app is correctly packaged and ready for distribution on the Google Play Console, regardless of its size.

Publishing to Google Play Store · React Native

Android requires that all apps be digitally signed with a certificate before they can be installed. In order to distribute your Android application via Google Play store it needs to be signed with a release key that then needs to be used for all future updates. Since 2017 it is possible for Google P…

React Native

react native: fix error for android release: Version code has already been used. Try another version code

Post, Code and Quiet Time.

react native: fix error for android release: Version code has already been used. Try another version code

By Errong Leng – 22 May 2024 – View online →

Photo by Victor Rosario / Unsplash

When you receive the error "Version code 1 has already been used. Try another version code." during the process of uploading an Android App Bundle (.aab) to the Google Play Console, it means that the version code you are trying to upload has already been used for a previous version of your app. The version code must be unique for each release.

Here’s how you can update the version code and version name in your Android project:

Step-by-Step Guide to Update Version Code

Open your project in Android Studio:

Navigate to your project directory and open it in Android Studio.

Locate the build.gradle file:

Find the build.gradle file for your app module (usually located at app/build.gradle).

Update the version code and version name:

In the build.gradle file, look for the defaultConfig block. It should look something like this:

android {      ...      defaultConfig {          applicationId "com.example.myapp"          minSdkVersion 16          targetSdkVersion 30          versionCode 1 # update version code          versionName "1.0" # update version name          ...      }  }

Increment the versionCode to a new integer value. The versionCode must be a positive integer and greater than the previous version codes used.

Optionally, you can also update the versionName to reflect the new version. This is typically a string like "1.0.1", "2.0", etc.

Example:

android {      ...      defaultConfig {          applicationId "com.example.myapp"          minSdkVersion 16          targetSdkVersion 30          versionCode 2          versionName "1.1"          ...      }  }

Sync the project:

After updating the build.gradle file, sync your project with the Gradle files by clicking "Sync Now" in the yellow notification bar that appears at the top of the editor, or by selecting "File" > "Sync Project with Gradle Files".

Rebuild your project:

Rebuild your project to generate the new .aab file with the updated version code. You can do this by selecting "Build" > "Build Bundle(s) / APK(s)" > "Build Bundle(s)" from the menu.

Upload the new .aab to Google Play Console:

Once the build process is complete, locate the new .aab file in your project directory (usually in app/build/outputs/bundle/release/).
Upload the new .aab file to the Google Play Console.

Summary

Open build.gradle (app module) in Android Studio.
Increment versionCode and update versionName.
Sync project with Gradle files.
Rebuild your project to generate a new .aab file.
Upload the new .aab to Google Play Console.

By following these steps, you should be able to resolve the error and successfully upload your new version to the Google Play Console.

Fixing Dynamic Router Issue in Spring Integration with Spring Boot 3.x Upgrade

Post, Code and Quiet Time.

Fixing Dynamic Router Issue in Spring Integration with Spring Boot 3.x Upgrade

By Errong Leng – 16 May 2024 – View online →

Photo by Dima Solomin / Unsplash

Introduction:

Spring Integration provides powerful tools for routing messages dynamically based on various criteria. However, upgrading to Spring Boot 3.x may introduce unexpected issues, particularly with dynamic routers configured using XML and annotated methods. In this post, we'll explore a common issue encountered after upgrading and discuss how to resolve it effectively.

Background:

In a Spring Integration application, dynamic routers play a crucial role in directing messages based on runtime conditions. These routers can be configured using XML or annotated methods, where you specify input channels, header names, and routing logic.

The Problem:

After upgrading to Spring Boot 3.x, dynamic routers with default output channels in XML configuration or annotated methods may stop working as expected. This issue arises because setting a default output channel also resets the channelKeyFallback option to false, starting from Spring Integration version 6.0. Unfortunately, there is no direct way to set channelKeyFallback to true explicitly in XML configuration.

partial code from AbstractMappingMessageRouter.java, the spring integration router implementation revealed why the router not worked after the upgrade.

	@Override  	public void setDefaultOutputChannel(MessageChannel defaultOutputChannel) {  		super.setDefaultOutputChannel(defaultOutputChannel);  		if (!this.channelKeyFallbackSetExplicitly) {  			this.channelKeyFallback = false;  		}  		this.defaultOutputChannelSet = true;  	}

  	private void addChannelFromString(Collection<MessageChannel> channels, String channelKey, Message<?> message) {  		if (channelKey.indexOf(',') != -1) {  			for (String name : StringUtils.tokenizeToStringArray(channelKey, ",")) {  				addChannelFromString(channels, name, message);  			}  			return;  		}    		// if the channelMappings contains a mapping, we'll use the mapped value  		// otherwise, the String-based channelKey itself will be used as the channel name  		String channelName = this.channelKeyFallback ? channelKey : null;  		boolean mapped = false;  		if (this.channelMappings.containsKey(channelKey)) {  			channelName = this.channelMappings.get(channelKey);  			mapped = true;  		}  		if (channelName != null) {  			addChannel(channels, message, channelName, mapped);  		}  	}

Solution:

There are two main options to address this issue in XML configuration:

Option A: Not Set Default Output Channel

By not setting the default output channel, the channelKeyFallback option remains unchanged, allowing the router to fallback to using channel names as keys.

Option B: Set Up Channel Mapping Explicitly

Define explicit channel mappings for all possible values of the header, ensuring that there are no unmatched cases.

Example Implementation:

<int:header-value-router input-channel="inputChannel" header-name="testHeader">      <int:mapping value="foo" channel="fooChannel" />      <int:mapping value="bar" channel="barChannel" />  </int:header-value-router>

Annotated Method:

@Router  public String failedServiceRoute(Message<Long> recordsFound) {      // ... return dynamic channel based on message header  }

Conclusion:

After upgrading to Spring Boot 3.x, it's essential to ensure that dynamic routers in your Spring Integration application continue to function properly. By understanding the changes in behaviour and following the recommended solutions provided in the Spring Integration documentation, you can resolve any issues efficiently. Whether opting not to set a default output channel or setting up explicit channel mappings, these strategies ensure proper message routing and maintain application functionality.

For more details, refer to the Spring Integration documentation and Dynamic Routers guide.

How to Fix "Clear Text Not Permitted" Issue in React Native Android App

Post, Code and Quiet Time.

How to Fix "Clear Text Not Permitted" Issue in React Native Android App

By Errong Leng – 15 May 2024 – View online →

Photo by Webstacks / Unsplash

Introduction

In React Native Android apps, you may encounter the "Clear Text Not Permitted" issue, especially when dealing with network requests. This error arises due to security measures introduced in Android 9 (API level 28) and higher, where clear text traffic (HTTP) is not allowed by default. In this post, we'll explore how to fix this issue and ensure your app communicates securely over HTTPS.

Problem Statement

The "Clear Text Not Permitted" issue occurs when your React Native Android app attempts to make network requests over HTTP, which is considered insecure.

Solution:

1. Use HTTPS for Network Requests

Ensure that all network requests in your app use HTTPS instead of HTTP. This includes requests to your backend API, external APIs, or any other network resources.

2. Update Android Manifest

Add the android:usesCleartextTraffic="true" attribute to the <application> element in your app's AndroidManifest.xml file:

<application android:usesCleartextTraffic="true" ...>

This allows clear text traffic for all network requests within your app, but it's recommended to use HTTPS instead.

3. Use Network Security Config

Create a network security configuration file (res/xml/network_security_config.xml) and allow clear text traffic:

<!-- res/xml/network_security_config.xml -->  <network-security-config>      <base-config cleartextTrafficPermitted="true">          <trust-anchors>              <!-- Trust preinstalled CAs -->              <certificates src="system" />          </trust-anchors>      </base-config>  </network-security-config>

Then, reference this file in your app's manifest:

<application      android:networkSecurityConfig="@xml/network_security_config"      ...>

4. Verify WebView Usage

If your app uses WebView, ensure it's not loading resources over HTTP. Use WebView.setMixedContentMode() to control mixed content.

5. Test Your App

Thoroughly test your app after making these changes to ensure that it functions as expected and that all network requests are secure.

Conclusion:By following these steps, you can fix the "Clear Text Not Permitted" issue in your React Native Android app and ensure that it complies with Android's network security requirements. It's crucial to prioritize security in your app's network communication to protect user data and maintain trust.

Remember, always use HTTPS for network requests to ensure the security and integrity of your app's data transmission.

Errong Leng

Map-based Implementations Deprecated: Overriding getDataSource in Spring Boot's DefaultBatchConfiguration

Step-by-Step Guide

Job Repository/Explorer Configuration Updates

How to Generate an .aab File in a React Native Project for Google Play Console

Why Use .aab Instead of .apk?

Steps to Generate an .aab File

1. Open Your Terminal

2. Navigate to the Android Directory

3. Run the Gradle Bundle Command

4. Locate the .aab File

Updating Version Code and Version Name

1. Open `build.gradle` (App Module)

2. Update `versionCode` and `versionName`

Summary

Important Note

react native: fix error for android release: Version code has already been used. Try another version code

Step-by-Step Guide to Update Version Code

Summary

Fixing Dynamic Router Issue in Spring Integration with Spring Boot 3.x Upgrade

How to Fix "Clear Text Not Permitted" Issue in React Native Android App

1. Use HTTPS for Network Requests

2. Update Android Manifest

3. Use Network Security Config

4. Verify WebView Usage

5. Test Your App

2026 Begins: Choosing to Stay on the Path as a Blogger

Report Abuse

Labels

Step-by-Step Guide

Job Repository/Explorer Configuration Updates

Why Use .aab Instead of .apk?

Steps to Generate an .aab File

1. Open Your Terminal

2. Navigate to the Android Directory

3. Run the Gradle Bundle Command

4. Locate the .aab File

Updating Version Code and Version Name

1. Open build.gradle (App Module)

2. Update versionCode and versionName

Summary

Important Note

Step-by-Step Guide to Update Version Code

Summary

1. Use HTTPS for Network Requests

2. Update Android Manifest

3. Use Network Security Config

4. Verify WebView Usage

5. Test Your App

1. Open `build.gradle` (App Module)

2. Update `versionCode` and `versionName`