CF-4258-JaxB Link builder

[ksrihari09]

Dynamic Domain Configuration for Atom Hopper Container

Problem Statement
The Atom Hopper container required hardcoded domain configuration for link building, which prevented dynamic switching between internal and external domains. In on-premise environments, there was functionality to dynamically configure domains, but this was lost in containerized deployments, potentially requiring separate container categories for different domain configurations.

Solution
Implemented dynamic domain configuration through environment variables, allowing the same container image to be used across different environments with appropriate domain settings.

Testing Instructions
Build and Basic Test

Build the updated image

cd docker
docker build -t atomhopper:test .

Test with custom external domain

docker run -d --name atomhopper-external -p 8080:8080
-e AH_DOMAIN=feeds.example.com
-e AH_SCHEME=https
atomhopper:test

Wait for startup

sleep 20

Create a test entry

curl -X POST -H "Content-Type: application/atom+xml"
-d '<title>Test Entry</title>Test content'
http://localhost:8080/namespace/feed

Verify links use custom domain

curl -s http://localhost:8080/namespace/feed | grep "https://feeds.example.com"

Cleanup

docker stop atomhopper-external && docker rm atomhopper-external

Expected Results
✅ Container starts successfully with custom domain configuration
✅ All Atom feed links use the configured domain and scheme
✅ Entry links contain the custom domain
✅ Configuration file is updated dynamically
✅ Original configuration is backed up
✅ Startup logs confirm domain configuration

[AJStieren]

For the image building, this should be building from local files so pulling the built artifact isn't making sense to me anymore.

Is there a reason alpine-slim was moved to alpine?

This is still making the AH_DOMAIN a single static URL that we're just passing in the container definition. The problem we're hitting is that we need to be able to build urls for both internal and external responses from the same atom hopper instance and providing only a single domain isn't really solving that problem. However, this is a good way to take this out of the environment variables so at least there is that.

[ksrihari09]

Changes Made:

• Local builds: Replaced remote Maven download with local WAR file copy

• Alpine-slim: Unavailable for ARM64 platform, reverted to alpine for compatibility

got this error for alpine-slim
`Dockerfile:4

2 | FROM tomcat:9.0-jdk8 as tomcat
3 |
4 | >>> FROM adoptopenjdk/openjdk8:alpine-slim
5 |
6 | LABEL maintainer="[email protected]" \

ERROR: failed to solve: adoptopenjdk/openjdk8:alpine-slim: failed to resolve source metadata for docker.io/adoptopenjdk/openjdk8:alpine-slim: no match for platform in manifest: not found`

• Dual domains: Added separate internal/external domain configuration with mode selection to support both simultaneously

[AJStieren]

Separating out the INTERNAL and EXTERNAL domains adds both variables to the Dockerfile, but does nothing to resolve the problem with Jax-B only taking a single domain to construct the return links. The current on-prem solution is able to dynamically construct links with the next and prev elements in the get feed returns based on the requesting URL. The proposal will still require a differentiation based on the external and internal Atom Hopper containers rather than letting a single container field requests from both.

Check how it currently works and try to pursue a method that will allow JaxB to reference the requester's URL instead of this weird switching thing that is effectively a nonfunctional variable to the start script.

[ksrihari09]

You're absolutely right about the core issue. I've implemented exactly what you suggested - request-based URL construction that allows JAX-B to reference the requester's URL directly.

What I Actually Implemented:

Single Container Solution - No need for separate internal/external containers
Dynamic URL Construction - URLs are built from the incoming request's Host header and X-Forwarded-Proto, not static environment variables
Request-Based Domain Resolution - The WorkspaceProvider.urlFor() method now extracts domain/scheme directly from the RequestContext