DEV Community: rinaxsumomo

How to Install OpenAPI (Swagger) Editor Plugin in Eclipse Offline

rinaxsumomo — Fri, 14 Nov 2025 10:15:23 +0000

TL;DR

If you need to install the 42Crunch OpenAPI (Swagger) Editor plugin in Eclipse without internet access, here’s the clean way to do it.

Environment

macOS Sonoma 14.x
Eclipse IDE (2025 edition for Mac)

Steps

Step 1: Prepare an Online Machine

You’ll first download the plugin from the official update site using Eclipse’s built-in p2 mirror tool.

Latest Update Site URL(As of 2025/11/14)
https://eclipse.42crunch.com/updatesite-1.0.95

Step2: Mirror the Update Site

On your online Mac machine, open Terminal and run:

# Go to Eclipse executable directory
cd /Applications/Eclipse.app/Contents/MacOS

# Mirror metadata
./eclipse \
-nosplash \
-application org.eclipse.equinox.p2.metadata.repository.mirrorApplication \
-source https://eclipse.42crunch.com/updatesite-1.0.95 \
-destination file:/Users/yourname/eclipse-mirror/42crunch

# Mirror artifacts
./eclipse \
-nosplash \
-application org.eclipse.equinox.p2.artifact.repository.mirrorApplication \
-source https://eclipse.42crunch.com/updatesite-1.0.95 \
-destination file:/Users/yourname/eclipse-mirror/42crunch

What these options mean:

-nosplash → No GUI splash screen
-application → Runs the p2 mirror tool
-source → Online update site URL
-destination → Local folder for the mirrored repository

Step 3: Zip the Repository

After mirroring, verify that the folder contains:

artifacts.jar
content.jar
features/
plugins/

Then zip it:

cd /Users/yourname/eclipse-mirror/42crunchzip -r 42crunch-openapi-p2.zip .

Step 4: Install Offline

On the offline machine:

Open Eclipse → Help → Install New Software → Add → Archive...
Select 42crunch-openapi-p2.zip
Install and restart Eclipse.

✅ Done! You now have the 42Crunch OpenAPI Editor installed without internet access.

✅ Tip: This method works for any Eclipse plugin that provides a p2 update site.

✅ Why p2 Mirror is Better Than Dropins
You might wonder: why not just copy JAR files into Eclipse’s dropins folder?
Here’s why p2 mirror is the recommended approach:

Dependency resolution: p2 ensures all required bundles and features are installed correctly.
Update support: Future updates can be applied easily using the same mirrored repository.
Clean uninstall: p2 tracks installed components, so you can remove them without breaking Eclipse.
Dropins is a hack: It bypasses p2, often causing version conflicts and missing dependencies.

Comparing AWS Route 53 Health Checks and CloudWatch Synthetics: Lightweight Website Monitoring for Production Readiness

rinaxsumomo — Tue, 20 May 2025 04:44:21 +0000

🛡️ Comparing AWS Route 53 Health Checks and CloudWatch Synthetics: Lightweight Website Monitoring for Production Readiness

When monitoring a web application's availability and reliability, especially for production frontends such as SPAs (Single Page Applications), AWS offers two native solutions: Route 53 Health Checks and CloudWatch Synthetics Canaries.

In this post, we’ll walk through the practical differences between them in terms of setup simplicity, cost, customizability, security, and reliability — with the goal of helping you choose the right one depending on your use case.

✅ Use Case Assumption

You want to:

Monitor the top page of a public-facing web app (e.g., https://example.com)
Confirm that it returns HTTP 200 status reliably
Detect failure and send alerts to Slack using AWS SNS + Chatbot
You do not need DNS failover or traffic redirection

🧭 Summary Table: Route 53 Health Check vs CloudWatch Synthetics

Feature	Route 53 Health Check	CloudWatch Synthetics Canary
Purpose	Basic uptime monitoring (HTTP status)	End-to-end synthetic testing
Protocol Support	HTTP, HTTPS	Full browser simulation
JavaScript Rendering	❌ Not supported	✅ Supported (Headless Chromium)
Custom Headers / Cookies	❌ Not supported	✅ Fully customizable
Cost (Approx.)	$0.50 / month per check	~$31 / month per 5-min interval
CloudWatch Metrics	✅ Native (`HealthCheckStatus`)	✅ Native (customizable metrics)
Alerting via SNS + Chatbot	✅ Supported	✅ Supported
Setup Complexity	Very simple	More involved (uses Lambda)
Multi-region Checks	✅ Multiple AWS regions by default	❌ Runs from a single region (unless duplicated)
SPA Suitability	Only if HTTP 200 is sufficient	Best for full rendering validation

🎯 When Route 53 Health Checks Are Ideal

Despite being often associated with DNS failover, Route 53 Health Checks can be used independently for monitoring purposes, even without DNS routing features. Here's when it shines:

You only need to check whether a specific URL returns 200 OK
You want a cost-effective and low-maintenance option
You want alerts via CloudWatch Alarm → SNS → Slack
You're not concerned with page content, rendering, or login redirection

It’s worth noting that even with SPAs, if your top-level HTML returns 200 and that’s your definition of “healthy,” this method is both sufficient and inexpensive.

⚠️ When You Might Need Synthetics Instead

If your requirements include:

Verifying if a SPA renders content properly
Checking redirects to login pages (e.g., due to expired sessions or API 401s)
Performing step-by-step flows or scripted behavior
Emulating authenticated users or handling cookies
Taking screenshots or logging failures in detail

Then CloudWatch Synthetics Canaries are much more appropriate. They allow headless browser scripting, can run in VPCs, and generate detailed logs and artifacts.

💬 Real-World Note: Cross-Account Resources

In many organizations — especially those adopting account-per-environment or account-per-purpose strategies — it’s common for the DNS (Route 53) to be managed in a different AWS account than the application infrastructure.

For example:

Route 53 DNS zone is in Account A (e.g., central domain/account team)
S3 bucket and CloudFront distribution (serving the SPA) are in Account B (e.g., owned by the app development team)

Even in this case, Route 53 Health Checks, CloudWatch Alarms, SNS Topics, and AWS Chatbot can be managed independently in either account. Since the health check only targets a public URL, it doesn’t require access to private resources.

This flexibility makes it easy to adopt Route 53-based health monitoring without restructuring your accounts or permissions — as long as the health check doesn’t need to modify Route 53 records (which is not necessary for notification-only use cases).

🔐 Security Consideration

Route 53 Health Checks are public and must reach a public endpoint.
Synthetics Canaries can run inside a VPC, allowing private API monitoring or intranet-facing systems.

💡 Final Recommendation

For basic availability monitoring where a 200 OK response is the only requirement, Route 53 Health Checks are the simplest, cheapest, and most reliable solution — especially when combined with CloudWatch Alarms + SNS + AWS Chatbot for Slack alerts.

However, if your application’s health depends on dynamic behavior or rendered content, investing in CloudWatch Synthetics Canaries is justified despite the higher cost.

Importing existing AWS IAM resources to Terraform

rinaxsumomo — Thu, 25 Apr 2024 07:34:40 +0000

Introduction

My project team created some AWS resources manually, but they wanted to bring this environment to another account. So here's Terraform. Using terraform import command, you can import existing resources to have Terraform manage.
In a nutshell, it's about updating tfstate file to reflect existing resources by this command, then reflecting the resources to main.tf (or other .tf files) to remove the differences between Terraform configuration and the real environment.

Environment

AWS
Terraform v1.7.5
Terraform Backend set to S3

Requirements

Basic knowledge of AWS
Basic knowledge of Terraform
IAM credentials that allow creating resources.

Terraform Directory design

Since we had different environment such as production, test, development, the Terraform directory is designed as below.
Also, we wanted to re-use codes, so we divided modules as below. VPC and IAM modules were developed.
There is iam.tf in /environment/test directory. This is the tf file to create IAM resource, developed in this post. This will be copied to the other environments as well.

.
├── environments
│ ├── dev
│ │ ├── main.tf
│ │ ├── terraform.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
│ ├── test
│ │ ├── iam.tf
│ │ ├── main.tf
│ │ ├── output.tf
│ │ ├── terraform.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
│ ├── prod
│ │ ├── main.tf
│ │ ├── terraform.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
├── modules
├── vpc
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── iam
├── policy
│ ├── main.tf
│ ├── output.tf
│ ├── policies
│ │ └── xxx_allow_policy.json
│ ├── terraform.tf
│ └── variables.tf
└── role
├── main.tf
├── output.tf
├── roles
│ ├── ec2.json
│ ├── lambda.json
│ └── s3.json
├── terraform.tf
└── variables.tf

Import

Add resource block to .tf file

First, you need to add empty resource blocks for your imported resources in main.tf.
In this case, I've added a new file, iam.tf acting as main.tf when running terraform apply command, and main.tf for IAM module called from iam.tf.
iam.tf is separated from main.tf in the environment directory for some operational reasons.
Below are the snippets.

# iam.tf in environment directory
module "iam_policy" {
  source = "../../modules/iam/policy"
}

module "iam_role" {
  source = "../../modules/iam/role"
}

You don't have to add arguments such as name or policy inside the block for now.

# main.tf in IAM Policy module directory
resource "aws_iam_policy" "test_policy" {
}

# main.tf in IAM Role module directory
resource "aws_iam_role" "test_role" {
}

Import IAM Policy

Here is the command and the result example.

$ terraform import module.iam_policy.aws_iam_policy.test_policy arn:aws:iam::1234567890:policy/test-policy
xxx...
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

Import IAM Role

Here is the command and the result example.

$ terraform import module.iam_role.aws_iam_role.test_role Test-Role
xxx...
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

Check the tfstate file

You should see that your imported resource is added in the tfstate file like below.

{
  "module": "module.iam_policy",
  "mode": "managed",
  "type": "aws_iam_policy",
  "name": "test_policy",
  "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
  "instances": [
    {
      "schema_version": 0,
      "attributes": {
        xxxx
      },
      "sensitive_attributes": [],
      "private": "xxx"
    }
  ]
}

Update main.tf in IAM Policy and Role module directory.

Now using the information added in the tfstate file, you need to add arguments in the resource blocks like below.
If you use JSON file for policies, you need to place them accordingly.

# main.tf in IAM Policy module directory
resource "aws_iam_policy" "test_policy" {
  name = "test-policy"
  policy = file("${path.module}/policies/xxx_allow_policy.json")
}

# main.tf in IAM Role module directory
resource "aws_iam_role" "Test_Role" {
  name   = "Test-Role"
  assume_role_policy = file("${path.module}/roles/s3.json")
  managed_policy_arns = ["arn:aws:iam::1234567890:policy/test-policy"]
}

Plan to check differences

Let's check if there are differences between Terraform configuration (imported ones) and the real resources in AWS. If you find differences (a kind of conflicts you might say), you need to resolve them. In this case, there are 6 differences as below. If the change was subtle, such as adding tags, you might apply this configuration change to the real resources, or you might modify other settings to resolve.

$ terraform plan
xxx...
Plan: 0 to add, 6 to change, 0 to destroy.

Note

If you failed to add resource blocks before importing, you should see an error as below.

Error: resource address "aws_iam_policy.test_policy" does not exist in the configuration.

Before importing this resource, please create its configuration in the root module. For example:

resource "aws_iam_policy" "test_policy" {
  # (resource arguments)
}

The arguments for importing IAM Policy and IAM Role are different. The former is ARN and the latter is Name. I wonder why indeed. If you used ARN by mistake to import IAM Role, the command would return Invalid error as below, which can be confusing.

│ Error: reading IAM Role (arn:aws:iam::1234567890:role/test-role): operation error IAM: GetRole, https response error StatusCode: 400, RequestID: 12345678-aaaa-bb12-cc34-1234567890, api error ValidationError: The specified value for roleName is invalid. It must contain only alphanumeric characters and/or the following: +=,.@_-

READ THE DOCUMENT!

If you imported wrong resources, you can remove them from Terraform state quickly as below. (This won't delete the real resources in AWS, no worry.)

Let's check if this would remove as you intend with dry-run.

$ terraform state rm --dry-run module.wrongmodule.aws_iam_policy.wrong_policy
Would remove module.wrongmodule.aws_iam_policy.wrong_policy

Then let's remove.

$ terraform state rm module.wrongmodule.aws_iam_policy.wrong_policy
Removed module.wrongmodule.aws_iam_policy.wrong_policy
Successfully removed 1 resource instance(s).

Conclusion

OK, I've imported all the IAM resources to Terraform configuration with some try&error. It's really important to read Terraform official document in detail..
Hoping this post would help.

References

How to change locale in Liberty Container image

rinaxsumomo — Thu, 27 Apr 2023 02:46:20 +0000

So you got WebSphere Liberty Container image based on Ubuntu from here.
And you'd like to change locale because you'd like to have logs in another language, such as Japanese, etc.
My procedure in this post is based on this but I think you need some additional steps, so here is how.
By the way my environment is MacOS Monterey 23.6.5, Apple M1Pro,using podman instead of docker. That's why I pulled amd64, of course you can get other architecture images depending on your environment.

1.Make Containerfile to install JP locale package and set environment variables with root.

FROM docker.io/amd64/websphere-liberty:23.0.0.3-full-java17-openj9
USER 0
RUN apt-get update \
 && apt-get install -y language-pack-ja \
 && rm -rf /var/lib/apt/lists/*
ENV LANG=ja_JP.UTF-8 \
  LANGUAGE=ja_JP:ja \
  LC_ALL=ja_JP.UTF-8 \
  TZ="Asia/Tokyo"
USER 1001

2.Build image.

$ podman build -t amd64-websphere-liberty:23.0.0.3-full-java17-openj9-jp .
STEP 1/5: FROM docker.io/amd64/websphere-liberty:23.0.0.3-full-java17-openj9
STEP 2/5: USER 0
--> Using cache 5d96bfdaf8d57c662ee86745b993e848d14849982ab17d543c9a872dbd469da2
--> 5d96bfdaf8d
STEP 3/5: RUN apt-get update  && apt-get install -y language-pack-ja  && rm -rf /var/lib/apt/lists/*
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal InRelease [265 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:5 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages [2,632 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [1,275 kB]
Get:7 http://security.ubuntu.com/ubuntu focal-security/multiverse amd64 Packages [28.5 kB]
Get:8 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages [1,035 kB]
Get:9 http://security.ubuntu.com/ubuntu focal-security/restricted amd64 Packages [2,145 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal/multiverse amd64 Packages [177 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal/restricted amd64 Packages [33.4 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages [11.3 MB]
Get:13 http://archive.ubuntu.com/ubuntu focal-updates/multiverse amd64 Packages [31.2 kB]
Get:14 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [1,331 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages [2,308 kB]
Get:16 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [3,125 kB]
Get:17 http://archive.ubuntu.com/ubuntu focal-backports/universe amd64 Packages [28.6 kB]
Get:18 http://archive.ubuntu.com/ubuntu focal-backports/main amd64 Packages [55.2 kB]
Fetched 26.2 MB in 20s (1,305 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
 language-pack-ja-base
The following NEW packages will be installed:
 language-pack-ja language-pack-ja-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 1,673 kB of archives.
After this operation, 7,786 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 language-pack-ja-base all 1:20.04+20220818 [1,671 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 language-pack-ja all 1:20.04+20220818 [1,900 B]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 1,673 kB in 2s (899 kB/s)
Selecting previously unselected package language-pack-ja-base.
(Reading database ... 7344 files and directories currently installed.)
Preparing to unpack .../language-pack-ja-base_1%3a20.04+20220818_all.deb ...
Unpacking language-pack-ja-base (1:20.04+20220818) ...
Selecting previously unselected package language-pack-ja.
Preparing to unpack .../language-pack-ja_1%3a20.04+20220818_all.deb ...
Unpacking language-pack-ja (1:20.04+20220818) ...
Setting up language-pack-ja (1:20.04+20220818) ...
Setting up language-pack-ja-base (1:20.04+20220818) ...
Generating locales (this might take a while)...
 ja_JP.UTF-8... done
Generation complete.
--> 64f2583a73b
STEP 4/5: ENV LANG=ja_JP.UTF-8   LANGUAGE=ja_JP:ja   LC_ALL=ja_JP.UTF-8   TZ="Asia/Tokyo"
--> 7aade810f7c
STEP 5/5: USER 1001
COMMIT amd64-websphere-liberty:23.0.0.3-full-java17-openj9-jp
--> 78bbe9bddab
Successfully tagged localhost/amd64-websphere-liberty:23.0.0.3-full-java17-openj9-jp
78bbe9bddab06db1abaca8c6d0b8e2ca59908ea979ec07adb833714f50ed8d00

3.Run from the image and see if successfully running.

$ podman images
REPOSITORY                                   TAG               IMAGE ID   CREATED    SIZE
localhost/amd64-websphere-liberty                       23.0.0.3-full-java17-openj9-jp 78bbe9bddab0 6 seconds ago 828 MB

$ podman run -d -p 9080:9080 -p 9443:9443 --name libertypodman localhost/amd64-websphere-liberty:23.0.0.3-full-java17-openj9-jp
5194c9971675cf84ce8dc9b609c7c44b44ea74c5b3b29f421d68ba47a318a8ba

$ podman ps -a
CONTAINER ID IMAGE                               COMMAND        CREATED    STATUS    PORTS                      NAMES
5194c9971675 localhost/amd64-websphere-liberty:23.0.0.3-full-java17-openj9-jp /opt/ibm/wlp/bin/... 4 seconds ago Up 4 seconds 0.0.0.0:9080->9080/tcp, 0.0.0.0:9443->9443/tcp libertypodman

4.Check the inside of the container to check if JP locale is set and logs are written in JP.

$ podman exec -it libertypodman /bin/sh
$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
ja_JP.utf8

$ locale
LANG=ja_JP.UTF-8
LANGUAGE=ja_JP:ja
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=ja_JP.UTF-8

$ cd logs
$ ls
messages.log
$ cat messages.log
********************************************************************************
product = WebSphere Application Server 23.0.0.3 (wlp-1.0.75.cl230320230319-1900)
wlp.install.dir = /opt/ibm/wlp/
server.output.dir = /opt/ibm/wlp/output/defaultServer/
java.home = /opt/java/openjdk
java.version = 17.0.6
java.runtime = IBM Semeru Runtime Open Edition (17.0.6+10)
os = Linux (5.17.5-300.fc36.aarch64; amd64) (ja_JP)
process = 1@5194c9971675
Classpath = /opt/ibm/wlp/bin/tools/ws-server.jar:/opt/ibm/wlp/bin/tools/ws-javaagent.jar
Java Library path = /opt/java/openjdk/lib/default:/opt/java/openjdk/lib:/usr/lib64:/usr/lib
********************************************************************************
[2023/04/26 14:21:22:376 JST] 00000001 com.ibm.ws.kernel.launch.internal.FrameworkManager      A CWWKE0001I: サーバー defaultServer が起動されました。
[2023/04/26 14:21:23:008 JST] 00000001 com.ibm.ws.kernel.launch.internal.FrameworkManager      A CWWKE0100I: この製品は、開発使用向け、および限定的な実動使用向けにライセンスが交付されています。 全ライセンス条項は以下で表示可能です: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/23.0.0.3/lafiles/ja.html
$ exit

Thanks.

Introduction to IBM App Connect

rinaxsumomo — Tue, 28 Sep 2021 12:44:02 +0000

Introduction

Although I'm used to IBM API Connect, I'm quite new to App Connect, which sounds very similar.
Now it's time for me to learn App Connect as well and this post is a kind of my note. As I'm familiar with creating APIs, I'm going to start with Creating a flow for an API.

Requirements

Get an IBM Cloud account (Lite or whatever). App Connect offers free edition that you don't need to pay to give a try.
Deploy IBM App Connect on the IBM Cloud console, quite easy and simple with one click.

Steps

Click "Create flows for an API".
Enter a name to represent your API.
Add properties as needed.
click operations to select operations and implement flows for each operation.
Set request parameters, name and location in this case.
Add applications as needed. In this try I'm not going to add any application.
Set response parameters for the name and location.
Click done and next.
Repeat the same procedure for GET flow by clicking Implement flow.
Set request parameters. Below is default setting.
Add applications as needed. In this try I'm not going to add any application as well, but I think this is the biggest point that differs from API Connect, as API Connect doesn't have such functions to integrate with other services.
Set response parameters for the name and location.
Click done
Start the API
Now the API is running.
Open Manage to check the API endpoint.
As this API is secured with API key by default. API key must be created to supply in API requests. In this try, I'm going to create API key for IBM Cloud internal use.
Click Create API key to generate one
Below is my API key
Now let's call the API with the key to POST (create) an entry.
Below is the request body and here's the response.
Now let's call the API to GET (retrieve) an entry. Note that this API is not the entry created above, it's irrelevant and this API simply returns the request parameter in the path in the response body, and the location parameter is fixed as set in Step 12-13.

Summary

Here I explained how to create an API flow with App Connect.

How to retry and log the final result in Bash

rinaxsumomo — Tue, 28 Sep 2021 07:23:22 +0000

I know there are lots of how-to write retry logic in Bash, such as here.

I've decided to use the one in the accepted answer above.
However I wanted to add another logic to log the final result as well, so I needed to modify this snippet as sleep always returns exit code 0 at last that logging depending on the exit code would not work as it always returns 0, even the command to be retried ended up with failure.

So here is my snippet. Below runs YOUR_COMMAND until success, 4 times for the maximum, and echo the result based on the exit code. This might not work depending on how YOUR_COMMAND returns a result, but it worked in my case.

NEXT_WAIT_TIME=0
RESULT=0
until [ ${NEXT_WAIT_TIME} -eq 4 ] || YOUR_COMMAND
do
    sleep $(( NEXT_WAIT_TIME++ ))
done
if [[ ${NEXT_WAIT_TIME} -eq 4 ]]; then
    RESULT=1
fi
if [[ ${RESULT} -eq 0 ]]; then
    echo "Command Successful"
else
    echo "Command Failed"
fi