Appendix

Accel Studio Testing Function Setup

The Accel Studio Testing Function Test Execution Agent (accelstudio-testing-agent) is not included in the main build targets. To use it, build the image and configure the environment variables separately.

Building the Image

docker compose build --no-cache accelstudio-testing-agent

Configuring the API Key and Base URL

Set the following environment variables in the .env file:

ACCELSTUDIO_TESTING_AGENT_ACCELPLATFORM_ACCESS_TOKEN: The API key issued from the iAP admin screen.
- Reference: Accel Studio Testing Function Usage Guide - Obtaining an API Key
ACCELSTUDIO_TESTING_AGENT_ACCELPLATFORM_BASE_URL: The base URL. Set this if you are not using the default http://127.0.0.1/imart. If the base URL is incorrect, the agent may fail to authenticate when accessing the test target URL.

Starting and Stopping

# Start the agent
docker compose up -d accelstudio-testing-agent

# Stop the agent
docker compose down accelstudio-testing-agent

If the agent's log (data/accelstudio-testing-agent/logs/accel_studio_testing_agent.log) outputs a message like the following during a test run, update ACCELSTUDIO_TESTING_AGENT_PLAYWRIGHT_VERSION in .env to the version indicated.

??????????????????????????????????????????????????????????
? Looks like Playwright was just updated to 1.60.0.      ?
? Please update docker image as well.                    ?
? -  current: mcr.microsoft.com/playwright:v1.59.1-noble ?
? - required: mcr.microsoft.com/playwright:v1.60.0-noble ?
?                                                        ?
? <3 Playwright Team                                     ?
??????????????????????????????????????????????????????????

In the example above, change to ACCELSTUDIO_TESTING_AGENT_PLAYWRIGHT_VERSION=1.60.0. After the change, a rebuild and restart are required.

docker compose build --no-cache accelstudio-testing-agent
docker compose up -d accelstudio-testing-agent

Checking Logs

Each service has two log channels: console output (stdout/stderr from the container) and file-based logs.

Console output: Check with the docker compose logs command. Adding the -f option enables live tailing; press Ctrl+C to exit.
File logs: Persisted under data/. These may contain more detail than console output, or information that does not appear in console output.

Choosing Between Console Output and File Logs

Console output is convenient for quickly identifying service startup status or obvious exceptions. For information not printed to the console—such as iAP application logs—or for more detailed information, use the file logs. Refer to the individual service descriptions below for what each service outputs to the console and where its file logs are stored.

The following describes the log check commands and file log locations for each service.

Resin (Application Server)

Logs for the Resin server itself and iAP's operation. In the default configuration, the console outputs logs notifying the server's operational status and logs when errors occur.

Standalone configuration:

docker compose logs -f resin

Cluster configuration:

docker compose logs -f resin1
docker compose logs -f resin2

Differences Between Resin1 and Resin2 Logs in the Cluster Configuration

resin1 and resin2 run from the same image with the same configuration, but they are independent processes. When troubleshooting, errors may appear in only one of them, so review both logs together.

File logs:

data/resin/log/imart/log/: Various iAP log files (for details, see intra-mart Accel Platform log specifications)
data/resin/log/resin/access.log: Resin HTTP access log

In the cluster configuration, logs are output under data/resin1/log/... and data/resin2/log/... respectively.

Apache HTTPd (Web Server)

Logs for the web server that receives external HTTP requests. The console outputs both access logs (common format) and error logs (warn level and above).

docker compose logs -f httpd

File logs:

data/httpd/log/access.log: Access log (common format; same content as console output)

Database

Logs for the iAP main database. The console outputs startup messages, connection errors, initialization, and other standard logs (query logs are not output by default).

docker compose logs -f <db> # <db> is the DB service name for the selected branch (e.g., postgresql)

File logs:

The file log location varies by database. See the README.md of the selected branch for details.

Cassandra (NoSQL Database)

Logs for Cassandra, used by iAP's IMBox. The console outputs general startup and initialization logs (including startup completion messages such as Binding thrift service to ... and Listening for thrift clients ...), as well as GC and commit log INFO messages.

docker compose logs -f cassandra

File logs:

data/cassandra/log/system.log: Cassandra system log

Solr (Search Engine)

Logs for Solr, used by iAP's search functionality. The console outputs startup completion messages such as Started SolrJettyServer, core load messages, various INFO logs, and errors on startup failure.

docker compose logs -f solr

File logs:

data/solr/logs/: Solr log files (solr.log, GC log solr_gc.log, slow query log solr_slow_requests.log, dated request logs YYYY_MM_DD.request.log, etc.)

mailpit (Test SMTP Server)

Logs for the test SMTP server that receives emails sent from iAP. The console outputs startup completion messages and logs when SMTP messages are received.

docker compose logs -f mailpit

File logs:

No file logs are output in this configuration (console output only).

accelstudio-testing-agent (Accel Studio Testing Function Test Execution Agent)

Logs for the Accel Studio Testing Function Test Execution Agent. The console outputs Spring Boot startup logs, Tomcat startup status (port 8188), Playwright-related plugin setup logs (including the execution of npm i @playwright/test), and logs when test execution requests are received.

docker compose logs -f accelstudio-testing-agent

File logs:

data/accelstudio-testing-agent/logs/accel_studio_testing_agent.log: Test Execution Agent log (same content as console output)

Collecting Logs for Troubleshooting

When a persistent issue occurs, using --tail=200 or a similar line count instead of -f to retrieve the end of the log makes it easier to share and investigate (→ Collecting Information When Issues Persist).

The data/ Directory: Description and Usage

The data/ directory is the area for persisting data from each service. As long as the contents under data/ are retained, the environment can resume from the previous state even after containers are stopped and restarted.

What Is Persisted (Standalone Configuration)

Path	Contents
`data/cassandra`	Cassandra data and system log
`data/httpd`	Apache HTTPd access log
`data/juggling`	IM-Juggling project, user modules to add, and artifacts (`project`, `additional-modules`, `public`, `war`, `repository`, etc.)
`data/mailpit`	mailpit email data
`data/<db>`	Database data. The directory name depends on the selected branch (see the selected branch's `README.md`).
`data/resin`	Resin logs, iAP logs, and storage area
`data/solr`	Solr index data
`data/accelstudio-testing-agent`	Accel Studio Testing Function Test Execution Agent log

What Is Persisted (Cluster Configuration)

Path	Contents
`data/cassandra`	Cassandra data and system log
`data/httpd`	Apache HTTPd access log
`data/juggling`	IM-Juggling project, user modules to add, and artifacts
`data/mailpit`	mailpit email data
`data/<db>`	Database data. The directory name depends on the selected branch (see the selected branch's `README.md`).
`data/resin/storage`	iAP storage area (shared by Resin1 and Resin2)
`data/resin1`	Resin1 logs and iAP logs
`data/resin2`	Resin2 logs and iAP logs
`data/solr`	Solr index data
`data/accelstudio-testing-agent`	Accel Studio Testing Function Test Execution Agent log

Backing Up and Migrating (Moving a Configured `data/` Directory)

Backing up data/ immediately after completing the tenant environment setup lets you skip the time-consuming tenant setup and quickly rebuild an equivalent environment.

# Back up (copy to a location of your choice)
cp -r data data.backup

To migrate to another machine, place the backed-up data/ at the same location in the new environment, then run docker compose up -d.

Replacing the IM-Juggling Project

To build an environment with a user-created IM-Juggling project, delete the contents of data/juggling/project and copy your IM-Juggling project there.

data/
└── juggling/
    └── project/
        ├── juggling.im
        ├── resin-web.xml
        ├── classes/
        ├── conf/
        ├── lib/
        ├── modules/
        └── schema/

The following files and directories must be present directly under the project directory:

juggling.im
resin-web.xml
conf/
modules/
schema/
classes/ (if needed)
lib/ (if needed)

After replacing, rebuild the war files and restart Resin and HTTPd.

# Build war and place static files
docker compose run --rm juggling-build-war

# For standalone configuration
docker compose restart resin
docker compose restart httpd

# For cluster configuration
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd

Configuration File Overwriting

Running docker compose run --rm juggling-build-war overwrites the configuration files under WEB-INF in the generated war with the configuration files bundled in this repository (under juggling-build-war/overwrite). The configuration files in the IM-Juggling project themselves are not changed. The files affected are: resin-web.xml, javamail-config.xml, accel-studio-testing-config.xml, cassandra-config.xml, network-agent-config.xml, server-context-config.xml, solr-config.xml, and storage-config.xml.

Resetting the Environment (Deleting the `data/` Directory)

To reset the data, stop the containers and delete the individual service directories under data/.

In the commands below, replace data/<db> with the database data directory for the selected branch (for example, data/postgresql for PostgreSQL). For the exact directory name, see the selected branch's README.md.

Standalone configuration:

docker compose down
# If the Test Execution Agent was started separately and is still running, also stop it:
# docker compose down accelstudio-testing-agent

sudo rm -rf data/cassandra data/httpd data/mailpit data/<db> data/resin data/solr data/accelstudio-testing-agent

docker compose up -d

Cluster configuration:

docker compose down
# If the Test Execution Agent was started separately and is still running, also stop it:
# docker compose down accelstudio-testing-agent

sudo rm -rf data/cassandra data/httpd data/mailpit data/<db> data/resin data/resin1 data/resin2 data/solr data/accelstudio-testing-agent

docker compose up -d

warning

Do Not Delete data/juggling/project

Deleting data/juggling/project will make it impossible to build war files and static files. If you only want to reset the Juggling artifacts, delete selectively as shown below, leaving project intact.

sudo rm -rf data/juggling/public data/juggling/repository data/juggling/war data/juggling/imart.war data/juggling/imart.zip

Adding Artifacts Partially

data/juggling/public and data/juggling/war are mounted into Apache HTTPd and Resin respectively. You can reflect changes without rebuilding the war by adding files directly to these directories and restarting the services.

# Standalone configuration
docker compose restart resin
docker compose restart httpd

# Cluster configuration
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd

In many cases, Apache HTTPd will pick up changes without requiring a restart.

Rebuilding the war and Static Files Removes Them

Running docker compose run --rm juggling-build-war recreates data/juggling/public and data/juggling/war, so any files you added directly are removed. For assets you want to keep using, incorporate them as a user module by following Adding User Modules.

Adding User Modules

This is the procedure for incorporating a user module you created into the environment's IM-Juggling project (data/juggling/project).

Place the user module file (.imm or .zip) under data/juggling/additional-modules:

data/
└── juggling/
    ├── project/
    └── additional-modules/
        └── <user module>.imm

Build the war and static files, then restart the services:

docker compose run --rm juggling-build-war

# Standalone configuration
docker compose restart resin
docker compose restart httpd

# Cluster configuration
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd

Before generating the war and static files, juggling-build-war incorporates the user modules under additional-modules into the IM-Juggling project and saves the project.

If the project already has a user module with the same module ID, it is replaced with the file you placed (including when the versions differ). To incorporate a new version, replace the file and build again.
The files you placed are incorporated on every build, in file name order. If you place multiple files with the same module ID, the later file replaces the earlier one, so place only one.
A user module with the same ID as a module retrieved from the repository, such as a base module or an application, cannot be incorporated and results in an error.
If validating the configuration or generating the war fails after the modules are incorporated, the project is restored to its state before incorporation. If it cannot be restored, the project from before incorporation remains in data/juggling/.project-backup, so restore it manually from there.

Deleting the File Does Not Remove the Module from the Project

Incorporated user modules are saved in the project's juggling.im and modules/. Deleting a file from additional-modules does not remove it from the project.

To remove one, delete the user module from the project with IM-Juggling (or the IM-Juggling library), then rebuild the war and static files.

Container Customization

Adding Debug Ports

To enable remote debugging for Resin, add the debug port to ports: for resin (or resin1 / resin2 in the cluster configuration) in compose.yaml.

# Example: exposing port 9009 as the debug port
ports:
  - 8080:8080
  - 9009:9009 # Add port

Also add the following argument to the jvm_args in resin/overwrite/conf/resin.properties:

-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:<port number>

Configuration example (using port 9009 as the debug port):

jvm_args : -Dfile.encoding=UTF-8 ... -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:9009

Applying Configuration Changes

If you modify ports: in compose.yaml, the containers must be recreated.

docker compose down
docker compose up -d

Removing Unnecessary Services from the Configuration (Cassandra / Solr, etc.)

If you cannot obtain Cassandra or Solr materials, or want to exclude them from the configuration, comment out the corresponding service definitions in compose.yaml and the relevant entries in depends_on for Resin.

The example below uses cassandra. To remove Solr, replace cassandra with solr. To remove both, comment out both services.

# Example: removing cassandra from the configuration (compose.yaml)
# For cluster configuration, edit depends_on for both resin1 and resin2

# cassandra:
#   image: $DOCKER_IMAGE_REPOSITORY/${DOCKER_IMAGE_TAG_PREFIX}cassandra:1.1.12
#   ...

resin: # resin1 / resin2 in cluster configuration
  ...
  depends_on:
    - postgresql
    # - cassandra
    - solr

Impact of Configuration Changes

When removing Cassandra or Solr, iAP must also be configured to not use those features. Review the relevant configuration files in the IM-Juggling project (cassandra-config.xml, solr-config.xml, etc.) as well.

Changing the Timezone

Modify the TZ environment variable in .env:

TZ=Asia/Tokyo

After changing .env, restart the containers to apply the change.

docker compose down
docker compose up -d

Command Reference

This section lists the frequently used Docker / Docker Compose commands from this guide, organized by purpose. Use this as a handy reference when working through this guide. For detailed prerequisites and notes for each command, see the section linked in the Reference column.

Substituting Service and Container Names

Some commands require substitution depending on the configuration and database you are using.

Replace <service name> with the applicable service name.
<container name> is the name of the actually running container (for example, docker-stacks_2026autumn-postgres-resin-1). You can find it in the NAME column of the docker compose ps output.

Building Images

Commands for generating each container image after cloning the repository and placing the required materials. The --no-cache option rebuilds cleanly without using the cache; this guide recommends always including it to ensure reproducibility.

Purpose	Command	Reference
Build all main container images	`docker compose build --no-cache`	Building Container Images
Build the image for building war and static files	`docker compose build --no-cache juggling-build-war`	Building Container Images
Build the Accel Studio Testing Function Test Execution Agent image	`docker compose build --no-cache accelstudio-testing-agent`	Accel Studio Testing Function Setup

Building and Deploying Artifacts (`run`)

Commands for starting containers as one-time processes rather than resident services. The --rm option automatically removes the container after it exits.

Purpose	Command	Reference
Build war and static files (also incorporates the user modules under `additional-modules`)	`docker compose run --rm juggling-build-war`	Building the war and Static Files / Adding User Modules

Start / Stop

Commands for starting and stopping all services that make up the iAP development environment.

Purpose	Command	Reference
Start all services in the background	`docker compose up -d`	Starting the Containers
Start all services in the foreground (to observe startup)	`docker compose up`	Starting the Containers
Stop all services	`docker compose down`	Stopping and Restarting Containers
Start only the Accel Studio Testing Function Test Execution Agent	`docker compose up -d accelstudio-testing-agent`	Accel Studio Testing Function Setup
Stop only the Accel Studio Testing Function Test Execution Agent	`docker compose down accelstudio-testing-agent`	Accel Studio Testing Function Setup

Restarting (Individual Services)

Commands for restarting specific services after configuration changes or during troubleshooting.

Purpose	Command	Reference
Restart a service	`docker compose restart <service name>`	Stopping and Restarting Containers / Restarting Individual Services (Standalone Configuration) / Restarting Individual Services (Cluster Configuration)

Checking Status and Logs

Commands for checking startup status and collecting information during troubleshooting. The -f option tails the log continuously (press Ctrl+C to exit); --tail=200 displays only the last 200 lines.

Purpose	Command	Reference
List container startup status	`docker compose ps`	Starting the Containers
Tail a service log	`docker compose logs -f <service name>`	Checking Logs
Display the last 200 lines of a service log (for sharing / investigation)	`docker compose logs --tail=200 <service name>`	Collecting Information When Issues Persist
Display detailed container information	`docker inspect <container name>`	Collecting Information When Issues Persist

Accel Studio Testing Function Setup​

Building the Image​

Configuring the API Key and Base URL​

Starting and Stopping​

Version-Related Errors​

Checking Logs​

Resin (Application Server)​

Apache HTTPd (Web Server)​

Database​

Cassandra (NoSQL Database)​

Solr (Search Engine)​

mailpit (Test SMTP Server)​

accelstudio-testing-agent (Accel Studio Testing Function Test Execution Agent)​

The data/ Directory: Description and Usage​

What Is Persisted (Standalone Configuration)​

What Is Persisted (Cluster Configuration)​

Backing Up and Migrating (Moving a Configured data/ Directory)​

Replacing the IM-Juggling Project​

Resetting the Environment (Deleting the data/ Directory)​

Adding Artifacts Partially​

Adding User Modules​

Container Customization​

Adding Debug Ports​

Removing Unnecessary Services from the Configuration (Cassandra / Solr, etc.)​

Changing the Timezone​

Command Reference​

Building Images​

Building and Deploying Artifacts (run)​

Start / Stop​

Restarting (Individual Services)​

Checking Status and Logs​

Accel Studio Testing Function Setup

Building the Image

Configuring the API Key and Base URL

Starting and Stopping

Version-Related Errors

Checking Logs

Resin (Application Server)

Apache HTTPd (Web Server)

Database

Cassandra (NoSQL Database)

Solr (Search Engine)

mailpit (Test SMTP Server)

accelstudio-testing-agent (Accel Studio Testing Function Test Execution Agent)

The data/ Directory: Description and Usage

What Is Persisted (Standalone Configuration)

What Is Persisted (Cluster Configuration)

Backing Up and Migrating (Moving a Configured `data/` Directory)

Replacing the IM-Juggling Project

Resetting the Environment (Deleting the `data/` Directory)

Adding Artifacts Partially

Adding User Modules

Container Customization

Adding Debug Ports

Removing Unnecessary Services from the Configuration (Cassandra / Solr, etc.)

Changing the Timezone

Command Reference

Building Images

Building and Deploying Artifacts (`run`)

Start / Stop

Restarting (Individual Services)

Checking Status and Logs