Fix Service Catalog failure when multiple services share context path on different listeners#25
Open
VellummyilumVinoth wants to merge 5 commits intoballerina-platform:mainfrom
Conversation
VellummyilumVinoth
requested review from
SasinduDilshara and
manuranga
as code owners
📝 WalkthroughWalkthroughThis PR updates the project version from 1.2.0 to 1.2.1, bumps dependencies (log to 2.17.0), modifies ServiceCatalog to generate UUID-based unique service names and simplify URL construction, changes publishArtifacts error handling to immediate propagation, and updates Dockerfiles with proper file ownership settings. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
test-resources/sample_project_8/Dependencies.toml (1)
257-263:⚠️ Potential issue | 🟠 MajorAlign
observeversion across all Dependencies.toml files.A version inconsistency exists: all test-resources sample projects pin
observeat1.7.1, while the main library (ballerina/Dependencies.toml) uses1.7.0. Additionally,ballerina-tests/mock-server/Dependencies.tomluses1.5.1. Update test projects to use1.7.0to match the main library and ensure consistent dependency resolution during builds.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_8/Dependencies.toml` around lines 257 - 263, Multiple test project Dependency.toml files pin the ballerina/observe package to mismatched versions (e.g., "version = \"1.7.1\"" and "1.5.1"); update every Dependencies.toml entry that declares [[package]] with org = "ballerina" and name = "observe" to set version = "1.7.0" so all projects match the main library and ensure consistent dependency resolution during builds.
♻️ Duplicate comments (5)
test-resources/sample_project_4/Dependencies.toml (1)
221-221: Duplicate: log 2.17.0 verification covered earlier.No additional action needed here if the repository-wide log version check passes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_4/Dependencies.toml` at line 221, This line duplicates an earlier log version check: verify that the repository-wide verification for the log dependency (version = "2.17.0") has already validated this version; if the global check passes, leave this occurrence unchanged, otherwise align or remove this duplicate to match the canonical version used by the repo (reference the entry "version = \"2.17.0\"" in Dependencies.toml).test-resources/sample_project_7/Dependencies.toml (1)
254-254: Duplicate: log 2.17.0 verification covered earlier.No additional action needed here if the repository-wide log version check passes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_7/Dependencies.toml` at line 254, This is a duplicate dependency-version entry for the log dependency (version = "2.17.0") in Dependencies.toml; no change is required if the repository-wide verification already asserted the same version—confirm the repository-wide check passes and either leave this line unchanged or remove the duplicate entry only if you prefer a single source of truth; locate the version = "2.17.0" entry in Dependencies.toml to verify consistency with the global log version check.test-resources/sample_project_10/Dependencies.toml (1)
221-221: Duplicate: log 2.17.0 verification covered earlier.No additional action needed here if the repository-wide log version check passes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_10/Dependencies.toml` at line 221, This is a duplicate check for the log version entry "version = \"2.17.0\"" in Dependencies.toml; verify the repository-wide log version check covers this same value and if so take no action (leave the line as-is and mark the PR comment as duplicate), otherwise consolidate by updating/removing the redundant entry so only the canonical version check remains; reference the literal version string "version = \"2.17.0\"" in Dependencies.toml when confirming or consolidating.test-resources/sample_project_0/Dependencies.toml (1)
221-221: Duplicate: log 2.17.0 verification covered earlier.No additional action needed here if the repository-wide log version check passes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_0/Dependencies.toml` at line 221, This entry "version = \"2.17.0\"" in Dependencies.toml is a duplicate of an earlier log v2.17.0 verification; if a repository-wide log version check already covers this, mark this comment/resolution as duplicate and take no further action (or remove the redundant check), otherwise ensure the repository-wide verification confirms log v2.17.0 and keep this line consistent with that check.test-resources/sample_project_4/Ballerina.toml (1)
5-15: Duplicate: build-options compatibility check.Same verification as in
sample_project_9/Ballerina.toml.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_4/Ballerina.toml` around lines 5 - 15, This is a duplicate compatibility check for the [build-options] block in Ballerina.toml (keys sticky and remoteManagement) already implemented for sample_project_9; remove the redundant validation and instead reuse or extract the shared compatibility logic so both sample_project_4 and sample_project_9 verify the same constraints, ensuring the check targets the [build-options] section and the sticky and remoteManagement keys consistently.
🧹 Nitpick comments (1)
test-resources/sample_project_8/Ballerina.toml (1)
8-9: Nit: inconsistent spacing around=within the same block.
sticky = trueuses standard TOML spacing, butremoteManagement=trueon the very next line does not. While TOML accepts both, keeping them consistent improves readability.♻️ Proposed fix
-remoteManagement=true +remoteManagement = true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_8/Ballerina.toml` around lines 8 - 9, The two TOML entries in Ballerina.toml are inconsistent: "sticky = true" uses spaces around '=' while "remoteManagement=true" does not; update the "remoteManagement" entry to match the spacing style used by "sticky" (i.e., change remoteManagement=true to remoteManagement = true) so both keys follow the same formatting convention.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@ballerina-tests/Dependencies.toml`:
- Line 249: The Dependencies.toml entry currently pins ballerina/log to a
non-existent "2.17.0" version; update the package version for ballerina/log to
"2.16.1" so dependency resolution succeeds (locate the version = "2.17.0" line
for the ballerina/log package and replace it with version = "2.16.1").
In `@ballerina-tests/mock-server/Dependencies.toml`:
- Around line 6-9: Dependencies.toml in the mock-server has out-of-sync stdlib
versions; regenerate the manifest using the same Ballerina distribution and
build configuration as the main test suite so stdlib versions match (e.g. update
log, observe, crypto, http to the versions used in the repo). Open the
mock-server Dependencies.toml (the [ballerina] section) and re-run the project
manifest generation with the same Ballerina distro used by the main tests so the
dependency entries for log, observe, crypto, http are replaced with the current
versions (match versions in the ballerina-tests manifest and gradle.properties)
to avoid resolution conflicts. Ensure the generated file reflects the same
distribution-version and stdlib versions as the other manifests.
In `@gradle.properties`:
- Around line 27-45: Update the stdlib version properties in gradle.properties
to match Dependencies.toml: change stdlibLogVersion to 2.17.0,
stdlibCryptoVersion to 2.10.1, stdlibMimeVersion to 2.12.1, stdlibTaskVersion to
2.11.1, stdlibHttpVersion to 2.15.4, and observeVersion (and
observeInternalVersion if needed) to 1.7.0 so the property keys
stdlibLogVersion, stdlibCryptoVersion, stdlibMimeVersion, stdlibTaskVersion,
stdlibHttpVersion, and observeVersion/observeInternalVersion align with the
generated Dependencies.toml manifests.
In `@native/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.java`:
- Around line 183-188: The updateServiceName method currently appends a random
UUID suffix which breaks idempotency; replace the UUID.randomUUID() usage in
updateServiceName with a deterministic suffix derived from the listener identity
available on HttpServiceConfig (e.g., host and port or listenerName). Compute a
stable short hash (MD5 or SHA-1) of that listener identity, take a fixed-length
substring (e.g., first 10 hex chars), normalize to uppercase, and append it to
httpServiceConfig.basePath when putting NAME into artifactValues; ensure you
remove the UUID call and use the new deterministic hash-based suffix so service
names remain stable across restarts while still unique per listener.
---
Outside diff comments:
In `@test-resources/sample_project_8/Dependencies.toml`:
- Around line 257-263: Multiple test project Dependency.toml files pin the
ballerina/observe package to mismatched versions (e.g., "version = \"1.7.1\""
and "1.5.1"); update every Dependencies.toml entry that declares [[package]]
with org = "ballerina" and name = "observe" to set version = "1.7.0" so all
projects match the main library and ensure consistent dependency resolution
during builds.
---
Duplicate comments:
In `@test-resources/sample_project_0/Dependencies.toml`:
- Line 221: This entry "version = \"2.17.0\"" in Dependencies.toml is a
duplicate of an earlier log v2.17.0 verification; if a repository-wide log
version check already covers this, mark this comment/resolution as duplicate and
take no further action (or remove the redundant check), otherwise ensure the
repository-wide verification confirms log v2.17.0 and keep this line consistent
with that check.
In `@test-resources/sample_project_10/Dependencies.toml`:
- Line 221: This is a duplicate check for the log version entry "version =
\"2.17.0\"" in Dependencies.toml; verify the repository-wide log version check
covers this same value and if so take no action (leave the line as-is and mark
the PR comment as duplicate), otherwise consolidate by updating/removing the
redundant entry so only the canonical version check remains; reference the
literal version string "version = \"2.17.0\"" in Dependencies.toml when
confirming or consolidating.
In `@test-resources/sample_project_4/Ballerina.toml`:
- Around line 5-15: This is a duplicate compatibility check for the
[build-options] block in Ballerina.toml (keys sticky and remoteManagement)
already implemented for sample_project_9; remove the redundant validation and
instead reuse or extract the shared compatibility logic so both sample_project_4
and sample_project_9 verify the same constraints, ensuring the check targets the
[build-options] section and the sticky and remoteManagement keys consistently.
In `@test-resources/sample_project_4/Dependencies.toml`:
- Line 221: This line duplicates an earlier log version check: verify that the
repository-wide verification for the log dependency (version = "2.17.0") has
already validated this version; if the global check passes, leave this
occurrence unchanged, otherwise align or remove this duplicate to match the
canonical version used by the repo (reference the entry "version = \"2.17.0\""
in Dependencies.toml).
In `@test-resources/sample_project_7/Dependencies.toml`:
- Line 254: This is a duplicate dependency-version entry for the log dependency
(version = "2.17.0") in Dependencies.toml; no change is required if the
repository-wide verification already asserted the same version—confirm the
repository-wide check passes and either leave this line unchanged or remove the
duplicate entry only if you prefer a single source of truth; locate the version
= "2.17.0" entry in Dependencies.toml to verify consistency with the global log
version check.
---
Nitpick comments:
In `@test-resources/sample_project_8/Ballerina.toml`:
- Around line 8-9: The two TOML entries in Ballerina.toml are inconsistent:
"sticky = true" uses spaces around '=' while "remoteManagement=true" does not;
update the "remoteManagement" entry to match the spacing style used by "sticky"
(i.e., change remoteManagement=true to remoteManagement = true) so both keys
follow the same formatting convention.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (37)
ballerina-tests/Dependencies.tomlballerina-tests/mock-server/.dockerignoreballerina-tests/mock-server/Dependencies.tomlballerina-tests/mock-server/Dockerfileballerina-tests/token-server/.dockerignoreballerina-tests/token-server/Dependencies.tomlballerina-tests/token-server/Dockerfileballerina/Dependencies.tomlballerina/service.balgradle.propertiesnative/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.javatest-resources/sample_project_0/Ballerina.tomltest-resources/sample_project_0/Dependencies.tomltest-resources/sample_project_1/Ballerina.tomltest-resources/sample_project_1/Dependencies.tomltest-resources/sample_project_10/Ballerina.tomltest-resources/sample_project_10/Dependencies.tomltest-resources/sample_project_11/Ballerina.tomltest-resources/sample_project_11/Dependencies.tomltest-resources/sample_project_12/Ballerina.tomltest-resources/sample_project_12/Dependencies.tomltest-resources/sample_project_2/Ballerina.tomltest-resources/sample_project_2/Dependencies.tomltest-resources/sample_project_3/Ballerina.tomltest-resources/sample_project_3/Dependencies.tomltest-resources/sample_project_4/Ballerina.tomltest-resources/sample_project_4/Dependencies.tomltest-resources/sample_project_5/Ballerina.tomltest-resources/sample_project_5/Dependencies.tomltest-resources/sample_project_6/Ballerina.tomltest-resources/sample_project_6/Dependencies.tomltest-resources/sample_project_7/Ballerina.tomltest-resources/sample_project_7/Dependencies.tomltest-resources/sample_project_8/Ballerina.tomltest-resources/sample_project_8/Dependencies.tomltest-resources/sample_project_9/Ballerina.tomltest-resources/sample_project_9/Dependencies.toml
💤 Files with no reviewable changes (1)
- ballerina/service.bal
VellummyilumVinoth
force-pushed
the
fix-for-multiple-listener
branch
from
90038d3 to
6971990
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (5)
test-resources/sample_project_11/Dependencies.toml (1)
218-227: Verifyballerina/log2.17.0 is published and compatible.This bump appears across the repo; please confirm availability for the 2201.13.x distribution line to avoid resolution failures.
Ballerina log 2.17.0 release availability Ballerina Central 2201.13.1 compatibility🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_11/Dependencies.toml` around lines 218 - 227, The dependency bump to ballerina/log version "2.17.0" in Dependencies.toml may not be available for the 2201.13.x distribution line; verify that package org="ballerina" name="log" version="2.17.0" is published and resolvable for your target distribution (e.g., check Ballerina Central and the 2201.13.x compatibility matrix). If it is not available, revert or pin all occurrences of ballerina/log to the latest confirmed compatible version for 2201.13.x (or update the distribution line), and update Dependencies.toml (and any other files where this bump appears) to use that confirmed version to avoid resolution failures during builds.test-resources/sample_project_1/Dependencies.toml (1)
252-261: Verifyballerina/log2.17.0 availability.Same concern as earlier: please confirm this version exists and is compatible with 2201.13.x.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_1/Dependencies.toml` around lines 252 - 261, The dependency entry [[package]] with org="ballerina" name="log" version="2.17.0" must be verified for existence and compatibility with Ballerina runtime 2201.13.x; check the package registry (or your internal artifact repo) to confirm that ballerina/log v2.17.0 is published and supports runtime 2201.13.x, and if it is not available/compatible, update the Dependencies.toml to a published compatible version (or pin the runtime to a compatible release), then re-run dependency resolution/build to ensure no breakage.ballerina-tests/Dependencies.toml (1)
246-259: Verifyballerina/log2.17.0 availability.Same concern as earlier: please confirm this version exists and is compatible with 2201.13.x.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ballerina-tests/Dependencies.toml` around lines 246 - 259, The dependency entry for org "ballerina" name "log" version "2.17.0" in Dependencies.toml must be verified for existence and compatibility with Ballerina 2201.13.x: check the Ballerina central (or your internal artifact registry) to confirm that version 2.17.0 of ballerina/log is published and listed as compatible with the 2201.13.x runtime, and if it is not available or incompatible, update the Dependencies.toml package block (the [[package]] entry for org="ballerina" name="log") to a published, compatible version or the range used by 2201.13.x, and re-run dependency resolution to ensure the change fixes the compatibility error.test-resources/sample_project_0/Dependencies.toml (1)
218-227: Verifyballerina/log2.17.0 availability.Same concern as earlier: please confirm this version exists and is compatible with 2201.13.x.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test-resources/sample_project_0/Dependencies.toml` around lines 218 - 227, Check that the declared package [[package]] with org="ballerina", name="log", version="2.17.0" actually exists and is compatible with Ballerina runtime 2201.13.x; if 2.17.0 is unavailable or incompatible, update the version string in this Dependencies.toml package block to a published release that is compatible with 2201.13.x (or pin to the project-approved version), then validate by running the dependency resolution/build to ensure no further dependency conflicts.native/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.java (1)
183-187:⚠️ Potential issue | 🟠 MajorReplace random UUID suffix with deterministic listener-derived suffix.
Line 183-187 still uses a random UUID, which makes service names (and MD5 in Line 152) change across restarts, causing catalog churn/duplicates. This was already flagged previously.
🔧 Suggested deterministic suffix (stable per listener)
- String uniqueSuffix = UUID.randomUUID().toString().replace("-", ""). - substring(0, 10).toUpperCase(Locale.ROOT); // To temporarily resolve service name uniqueness conflicts + String uniqueSuffix = createMd5Hash(httpServiceConfig.host + COLON + httpServiceConfig.port) + .substring(0, 10).toUpperCase(Locale.ROOT); // Stable per listener artifactValues.put(StringUtils.fromString(NAME), StringUtils.fromString(httpServiceConfig.basePath + uniqueSuffix));🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@native/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.java` around lines 183 - 187, updateServiceName currently appends a random UUID which makes service names and the MD5 at line 152 unstable; replace the random suffix with a deterministic, listener-derived suffix (for example compute a stable hash of a listener identifier or the listener host:port available on the HttpServiceConfig) instead of UUID.randomUUID(), then truncate/uppercase to 10 chars as before and set artifactValues.put(NAME, ...) using that value; also ensure the same deterministic value is used when computing the MD5 so names and IDs remain stable across restarts (refer to updateServiceName, artifactValues, httpServiceConfig, and the MD5 generation code near line 152).
🧹 Nitpick comments (1)
ballerina-tests/token-server/Dockerfile (1)
24-34: Consider dropping to a non-root user in the runtime stage.The builder stage now correctly sets ownership to
ballerina:ballerina, but the finaleclipse-temurin:21-jrestage has noUSERdirective, so the container process runs as root. Even for a test-only token server, running as root unnecessarily widens the blast radius on container escape.🔒 Proposed hardening for Stage 2
FROM eclipse-temurin:21-jre WORKDIR /app -COPY --from=builder /app/target/bin/apim_catalog_token_server.jar /app/token-server.jar +RUN groupadd --gid 1000 ballerina && useradd --uid 1000 --gid ballerina --no-create-home ballerina +COPY --chown=ballerina:ballerina --from=builder /app/target/bin/apim_catalog_token_server.jar /app/token-server.jar ENV PORT=9444 ENV KEYSTORE_PATH=/resources/ballerinaKeystore.p12 ENV KEYSTORE_PASSWORD=ballerina +USER ballerina EXPOSE ${PORT} ENTRYPOINT ["java", "-jar", "/app/token-server.jar"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ballerina-tests/token-server/Dockerfile` around lines 24 - 34, The runtime stage currently uses FROM eclipse-temurin:21-jre and runs as root (no USER), so add a non-root user and switch to it before ENTRYPOINT; create or reuse the same ballerlina user/group used in the builder stage (or create a new unprivileged user), ensure the copied artifact (/app/token-server.jar) and any mounted resource paths (KEYSTORE_PATH) are owned by that user (adjust ownership after COPY), and add a USER directive so the java -jar ENTRYPOINT runs as the non-root account.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@ballerina-tests/Dependencies.toml`:
- Around line 246-259: The dependency entry for org "ballerina" name "log"
version "2.17.0" in Dependencies.toml must be verified for existence and
compatibility with Ballerina 2201.13.x: check the Ballerina central (or your
internal artifact registry) to confirm that version 2.17.0 of ballerina/log is
published and listed as compatible with the 2201.13.x runtime, and if it is not
available or incompatible, update the Dependencies.toml package block (the
[[package]] entry for org="ballerina" name="log") to a published, compatible
version or the range used by 2201.13.x, and re-run dependency resolution to
ensure the change fixes the compatibility error.
In `@native/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.java`:
- Around line 183-187: updateServiceName currently appends a random UUID which
makes service names and the MD5 at line 152 unstable; replace the random suffix
with a deterministic, listener-derived suffix (for example compute a stable hash
of a listener identifier or the listener host:port available on the
HttpServiceConfig) instead of UUID.randomUUID(), then truncate/uppercase to 10
chars as before and set artifactValues.put(NAME, ...) using that value; also
ensure the same deterministic value is used when computing the MD5 so names and
IDs remain stable across restarts (refer to updateServiceName, artifactValues,
httpServiceConfig, and the MD5 generation code near line 152).
In `@test-resources/sample_project_0/Dependencies.toml`:
- Around line 218-227: Check that the declared package [[package]] with
org="ballerina", name="log", version="2.17.0" actually exists and is compatible
with Ballerina runtime 2201.13.x; if 2.17.0 is unavailable or incompatible,
update the version string in this Dependencies.toml package block to a published
release that is compatible with 2201.13.x (or pin to the project-approved
version), then validate by running the dependency resolution/build to ensure no
further dependency conflicts.
In `@test-resources/sample_project_1/Dependencies.toml`:
- Around line 252-261: The dependency entry [[package]] with org="ballerina"
name="log" version="2.17.0" must be verified for existence and compatibility
with Ballerina runtime 2201.13.x; check the package registry (or your internal
artifact repo) to confirm that ballerina/log v2.17.0 is published and supports
runtime 2201.13.x, and if it is not available/compatible, update the
Dependencies.toml to a published compatible version (or pin the runtime to a
compatible release), then re-run dependency resolution/build to ensure no
breakage.
In `@test-resources/sample_project_11/Dependencies.toml`:
- Around line 218-227: The dependency bump to ballerina/log version "2.17.0" in
Dependencies.toml may not be available for the 2201.13.x distribution line;
verify that package org="ballerina" name="log" version="2.17.0" is published and
resolvable for your target distribution (e.g., check Ballerina Central and the
2201.13.x compatibility matrix). If it is not available, revert or pin all
occurrences of ballerina/log to the latest confirmed compatible version for
2201.13.x (or update the distribution line), and update Dependencies.toml (and
any other files where this bump appears) to use that confirmed version to avoid
resolution failures during builds.
---
Nitpick comments:
In `@ballerina-tests/token-server/Dockerfile`:
- Around line 24-34: The runtime stage currently uses FROM
eclipse-temurin:21-jre and runs as root (no USER), so add a non-root user and
switch to it before ENTRYPOINT; create or reuse the same ballerlina user/group
used in the builder stage (or create a new unprivileged user), ensure the copied
artifact (/app/token-server.jar) and any mounted resource paths (KEYSTORE_PATH)
are owned by that user (adjust ownership after COPY), and add a USER directive
so the java -jar ENTRYPOINT runs as the non-root account.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (36)
ballerina-tests/Ballerina.tomlballerina-tests/Dependencies.tomlballerina-tests/mock-server/Dockerfileballerina-tests/token-server/Dockerfileballerina/Ballerina.tomlballerina/CompilerPlugin.tomlballerina/Dependencies.tomlballerina/service.balgradle.propertiesnative/src/main/java/io/ballerina/wso2/apim/catalog/ServiceCatalog.javatest-resources/sample_project_0/Ballerina.tomltest-resources/sample_project_0/Dependencies.tomltest-resources/sample_project_1/Ballerina.tomltest-resources/sample_project_1/Dependencies.tomltest-resources/sample_project_10/Ballerina.tomltest-resources/sample_project_10/Dependencies.tomltest-resources/sample_project_11/Ballerina.tomltest-resources/sample_project_11/Dependencies.tomltest-resources/sample_project_12/Ballerina.tomltest-resources/sample_project_12/Dependencies.tomltest-resources/sample_project_2/Ballerina.tomltest-resources/sample_project_2/Dependencies.tomltest-resources/sample_project_3/Ballerina.tomltest-resources/sample_project_3/Dependencies.tomltest-resources/sample_project_4/Ballerina.tomltest-resources/sample_project_4/Dependencies.tomltest-resources/sample_project_5/Ballerina.tomltest-resources/sample_project_5/Dependencies.tomltest-resources/sample_project_6/Ballerina.tomltest-resources/sample_project_6/Dependencies.tomltest-resources/sample_project_7/Ballerina.tomltest-resources/sample_project_7/Dependencies.tomltest-resources/sample_project_8/Ballerina.tomltest-resources/sample_project_8/Dependencies.tomltest-resources/sample_project_9/Ballerina.tomltest-resources/sample_project_9/Dependencies.toml
💤 Files with no reviewable changes (1)
- ballerina/service.bal
🚧 Files skipped from review as they are similar to previous changes (14)
- test-resources/sample_project_7/Ballerina.toml
- test-resources/sample_project_12/Dependencies.toml
- test-resources/sample_project_12/Ballerina.toml
- ballerina-tests/mock-server/Dockerfile
- gradle.properties
- test-resources/sample_project_2/Dependencies.toml
- test-resources/sample_project_7/Dependencies.toml
- test-resources/sample_project_10/Dependencies.toml
- test-resources/sample_project_4/Dependencies.toml
- test-resources/sample_project_3/Ballerina.toml
- ballerina/Dependencies.toml
- test-resources/sample_project_10/Ballerina.toml
- test-resources/sample_project_6/Dependencies.toml
- test-resources/sample_project_6/Ballerina.toml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Examples
Checklist
Summary
This pull request addresses a service naming conflict issue in the APIM Service Catalog when multiple services share the same context path on different listeners. The changes include:
Functional Improvements
Service Uniqueness Enhancement: Modified the service naming logic to append a unique 10-character UUID-based suffix to service names, ensuring that services with identical context paths on different listeners can be properly differentiated and registered without conflicts.
Service URL Simplification: Streamlined the service URL construction logic to use consistent host:port:basePath composition, removing conditional handling that was previously specific to certain deployment scenarios.
Error Handling Refinement: Changed artifact publishing from collecting errors across all services to immediately halting on the first error. This provides fail-fast semantics during service registration, which improves feedback clarity when issues occur.
Dependency and Infrastructure Updates
Testing Artifacts
Updated all sample test projects and their configuration files to use the new versions, ensuring consistency across the test suite.
The changes improve service registration reliability and clarity while maintaining backward compatibility with existing service catalog functionality.