[Automated] Sync master after 2201.13.6 release - #6415
[Automated] Sync master after 2201.13.6 release#6415ballerina-cicd-bot wants to merge 179 commits into
Conversation
Update License file
[2201.13.x] Update observei version
[Automated] Sync master after 2201.13.0 release
Update mcp and ai version
Update lang version
Add entries to trivy ignore
[Automated] Sync master after 2201.13.1 release
Include sticky and offline flags for bbe tests
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Bump the http, tcp version for 2201.13.5 release
[2201.13.x] Update the ftp version to 2.20.1
…ion-20260722 Update lang version
Update stdlibEdiVersion and stdlibFtpVersion
[Automated] Sync master after 2201.13.5 release
…ities-2201.13.x Add trivy ignore entries for jackson and netty CVEs
|
|
📝 WalkthroughWalkthroughThe pull request updates release metadata, dependency and license records, offline build behavior, integration coverage, logging examples, XML and MCP examples, and example documentation. ChangesDistribution update
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
🧪 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: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish-release.yml:
- Around line 118-121: Update the workflow action versions at
.github/workflows/publish-release.yml lines 118-121 and 704-706: replace
actions/setup-node@v2 and actions/setup-dotnet@v1 with supported releases,
respectively, while preserving their existing configuration and workflow
behavior.
In @.trivyignore:
- Around line 8-22: Upgrade the bundled Jackson dependencies referenced by
ballerina/LICENSE to at least 2.18.8/2.21.4 and Netty native transport
dependencies to at least 4.1.135.Final/4.2.15.Final, then remove the
corresponding CVE and GHSA entries from .trivyignore so the release scan reports
no suppressed unresolved vulnerabilities.
In `@ballerina/build.gradle`:
- Around line 964-966: Update the Windows command construction around the
needCentral condition to store --sticky and --offline as separate option
elements, rather than appending them to one argument string. Pass the options
list when invoking bal.bat, and only join the complete command for the shell
execution.
In `@ballerina/LICENSE`:
- Around line 167-225: Regenerate the bundled license inventory in
ballerina/LICENSE from the current generated release artifacts rather than
manually retaining stale JAR entries. Update all listed dependency versions,
including ballerina-time, ballerina-data.xmldata, ballerina-log,
ballerina-crypto, and any other resolved artifacts, so the shipped license
notice exactly matches the distribution.
In `@examples/custom-logger/custom_logger.bal`:
- Around line 64-69: Update withContext so the contextual logger retains the
parent logger’s dynamic level binding instead of copying self.level, and ensure
child setLevel returns the log API’s unsupported-operation error. Add a test
that creates a child, changes the parent level afterward, and verifies the child
reflects the updated level.
- Around line 10-18: Update the logger print methods to honor the configured
level through the existing level accessor or comparison semantics: add ordering
checks in printInfo, printWarn, printError, and printDebug, and delegate to the
corresponding log functions only when enabled. Ensure all four levels emit
appropriately while disabled levels produce no output, preserving the log:Logger
contract for getLevel/setLevel.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 81c76bd6-869f-48eb-bd18-aeab926df9c8
⛔ Files ignored due to path filters (8)
examples/log-file-rotation/app_log_rotation.outis excluded by!**/*.outexamples/log-file-rotation/log_file_rotation.outis excluded by!**/*.outexamples/logger-from-config/audit_logs.outis excluded by!**/*.outexamples/logger-from-config/logger_from_config.outis excluded by!**/*.outexamples/logger-from-config/metrics_logs.outis excluded by!**/*.outexamples/xml-from-json-conversion/xml_from_json_conversion.outis excluded by!**/*.outexamples/xml-to-json-conversion/xml_to_json_conversion.outis excluded by!**/*.outexamples/xml-to-record-conversion/xml_to_record_conversion.outis excluded by!**/*.out
📒 Files selected for processing (36)
.github/workflows/publish-release.yml.trivyignoreballerina-test-automation/gradle.propertiesballerina/LICENSEballerina/build.gradlebuild.gradleexamples/azure-functions-cosmosdb-trigger/azure_functions_cosmosdb_trigger.mdexamples/custom-logger/custom_logger.balexamples/http-access-logs/Config.tomlexamples/http-access-logs/http_access_logs.mdexamples/http-trace-logs/Config.tomlexamples/http-trace-logs/http_trace_logs.mdexamples/index.jsonexamples/log-file-rotation/Config.tomlexamples/log-file-rotation/log_file_rotation.balexamples/log-file-rotation/log_file_rotation.mdexamples/log-file-rotation/log_file_rotation.metatagsexamples/logger-from-config/logger_from_config.balexamples/logger-from-config/logger_from_config.mdexamples/logging-configuration/Config.tomlexamples/logging-configuration/logging_configuration.mdexamples/mcp-service-advanced/mcp_service_advanced.balexamples/natural-expressions/natural_expressions.mdexamples/string-templates/string_templates.mdexamples/xml-from-json-conversion/xml_from_json_conversion.balexamples/xml-from-json-conversion/xml_from_json_conversion.mdexamples/xml-from-record-conversion/xml_from_record_conversion.balexamples/xml-from-record-conversion/xml_from_record_conversion.mdexamples/xml-to-json-conversion/xml_to_json_conversion.balexamples/xml-to-json-conversion/xml_to_json_conversion.mdexamples/xml-to-record-conversion/xml_to_record_conversion.balexamples/xml-to-record-conversion/xml_to_record_conversion.mdgradle.propertiesstdlib-integration-tests/index.jsonstdlib-integration-tests/library_package_test/Ballerina.tomlstdlib-integration-tests/library_package_test/main.bal
| - name: Set up Node.js | ||
| uses: actions/setup-node@v2 | ||
| with: | ||
| node-version: '14' | ||
| node-version: "14" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow snippets =="
sed -n '90,135p' .github/workflows/publish-release.yml || true
sed -n '690,715p' .github/workflows/publish-release.yml || true
echo "== actionlint availability =="
if command -v actionlint >/dev/null 2>&1; then
actionlint --version || true
actionlint .github/workflows/publish-release.yml 2>&1 || true
else
echo "actionlint not installed"
fi
echo "== npm/actionlint availability =="
if command -v npm >/dev/null 2>&1; then
npx --no-install actionlint --version 2>&1 || true
else
echo "npm not available"
fi
echo "== check pinned action refs vs upstream tags =="
python3 - <<'PY'
from urllib.request import urlopen
import json
import re
repo_map = {
("actions","setup-node"): "https://api.github.com/repos/actions/setup-node/git/refs/tags/v2",
("actions","setup-dotnet"): "https://api.github.com/repos/actions/setup-dotnet/git/refs/tags/v1",
}
tags = ["v2", "v1"]
for (owner, repo), url in repo_map.items():
print(f"## {owner}/{repo}")
data = None
try:
req = urlopen(url, timeout=10)
data = json.load(req)
except Exception as e:
print("GET", url, type(e).__name__, s := getattr(e, "code", None))
if data:
print("ref:", data.get("ref"))
obj = data.get("object", {})
print("object_type:", obj.get("type"))
if obj.get("type") == "tag":
tag_obj = json.load(urlopen(obj["url"], timeout=10))
print("dereferenced_commit:", tag_obj.get("object", {}).get("sha"))
else:
print("commit:", obj.get("sha"))
# current branch HEAD for context
ref_json = json.load(urlopen(f"https://api.github.com/repos/{owner}/{repo}/git/refs/heads/main", timeout=10))
print("main_sha:", ref_json.get("object", {}).get("sha"))
PYRepository: ballerina-platform/ballerina-distribution
Length of output: 6952
🌐 Web query:
GitHub Actions actions/setup-node v2 support deprecated GitHub Actions v2 Node 16 removed
💡 Result:
The actions/setup-node v2 action is effectively deprecated, and relying on it in modern workflows is strongly discouraged due to its outdated underlying runtime [1][2][3]. Key details regarding this deprecation: 1. Outdated Runtime: The actions/setup-node v2 action was built using an older Node.js runtime (Node 16) [4]. Node 16 itself has reached end-of-life (EOL), and GitHub has mandated that GitHub Actions must transition to newer, supported Node.js versions (e.g., Node 20 and Node 24) for the action runners themselves [5][3]. 2. Upgrade Recommendation: You should update your workflows to use the latest major version of the action (currently v7) [2][6][7]. Newer versions of actions/setup-node have been updated to support modern Node.js environments and include critical improvements, such as updated runtime support (e.g., Node 24) [1][2][7]. 3. Why "Node 16 Removed" Matters: When GitHub performs environment upgrades on hosted runners, workflows using actions/setup-node v2 may trigger warnings, fail, or experience compatibility issues because the action's internal implementation depends on a runtime version that is no longer recommended or supported by GitHub's infrastructure [8][3]. To resolve any issues, update your workflow files from: - uses: actions/setup-node@v2 To: - uses: actions/setup-node@v7 [6][7] Check the official actions/setup-node repository releases for any specific breaking changes you might need to address when upgrading from v2 to v7 [1][2].
Citations:
- 1: https://github.com/actions/setup-node/
- 2: https://github.com/actions/setup-node/tree/refs/heads/main
- 3: Node 16 deprecation actions/setup-node#850
- 4: actions/setup-node@v2...v3.0.0
- 5: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
- 6: https://github.com/marketplace/actions/setup-node-js-environment
- 7: https://github.com/actions/setup-node
- 8: What's the relevance of warnings on 'deprecated' Node versions? actions/setup-node#964
🌐 Web query:
GitHub Actions actions/setup-dotnet v1 support deprecated GitHub Actions v1 Node 16 removed
💡 Result:
The actions/setup-dotnet v1 action is long deprecated and incompatible with modern GitHub Actions environments, which have moved past Node 16 [1][2][3]. Key details regarding this deprecation: 1. Node 16 Removal: GitHub Actions removed support for Node 16 on November 12, 2024 [2]. All GitHub-hosted runners now require actions to run on newer Node.js versions (specifically Node 20, with a transition to Node 24 occurring throughout 2026) [2][4]. Any action attempting to run on Node 16 will fail [2][3]. 2. Actions/setup-dotnet Evolution: - Version v1 is obsolete and no longer supported [5][6]. - As of August 2026, the current major version is v6 [6]. - You should migrate immediately to the latest version (v6 or higher) to ensure compatibility with current runner images and modern Node.js requirements [7][6]. 3. Recommended Action: Update your workflow YAML files to replace actions/setup-dotnet@v1 with the latest version, such as: - uses: actions/setup-dotnet@v6 Using the latest version also provides access to newer features, such as the ability to specify dotnet-version: latest for automatic SDK resolution [8][9]. For further details on the transition from older Node versions, see the official GitHub Actions changelog regarding Node 16 [2] and Node 20 [4] deprecations.
Citations:
- 1: Node.js 16 actions are deprecated actions/setup-dotnet#503
- 2: https://github.blog/changelog/2024-09-25-end-of-life-for-actions-node16/
- 3: https://github.blog/changelog/2024-03-06-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/
- 4: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
- 5: Node.js 12 actions are deprecated. actions/setup-dotnet#420
- 6: https://github.com/actions/setup-dotnet/releases
- 7: https://github.com/actions/setup-dotnet?tab=readme-ov-file
- 8: Add dotnet-version: latest support with dotnet-channel input actions/setup-dotnet#730
- 9: Allow specifying 'latest' as dotnet-version actions/setup-dotnet#497
Update the unsupported setup actions.
actionlint reports that these pinned actions cannot run on current GitHub Actions runners because the action runtimes are deprecated. Update each action to a supported release before using this workflow for publishing.
.github/workflows/publish-release.yml#L118-L121: Replaceactions/setup-node@v2with a supported version..github/workflows/publish-release.yml#L704-L706: Replaceactions/setup-dotnet@v1with a supported version.
🧰 Tools
🪛 actionlint (1.7.12)
[error] 119-119: the runner of "actions/setup-node@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
📍 Affects 1 file
.github/workflows/publish-release.yml#L118-L121(this comment).github/workflows/publish-release.yml#L704-L706
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish-release.yml around lines 118 - 121, Update the
workflow action versions at .github/workflows/publish-release.yml lines 118-121
and 704-706: replace actions/setup-node@v2 and actions/setup-dotnet@v1 with
supported releases, respectively, while preserving their existing configuration
and workflow behavior.
Source: Linters/SAST tools
| CVE-2026-56740 | ||
| CVE-2026-56741 | ||
|
|
||
| # jackson-core / jackson-databind - needs dependency upgrade to 2.18.8+/2.21.4+ | ||
| GHSA-r7wm-3cxj-wff9 | ||
| CVE-2026-54512 | ||
| CVE-2026-54513 | ||
| CVE-2026-54514 | ||
| CVE-2026-54515 | ||
| CVE-2026-59888 | ||
| CVE-2026-59889 | ||
| GHSA-mhm7-754m-9p8w | ||
|
|
||
| # netty-transport-native-epoll / netty-transport-native-kqueue - needs dependency upgrade to 4.1.135.Final/4.2.15.Final+ | ||
| CVE-2026-45536 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not suppress unresolved vulnerabilities.
Lines 8-22 classify these findings as needing a fix, but .trivyignore suppresses them during the release scan. The bundled Jackson and Netty versions in ballerina/LICENSE are below the stated fixed versions. Upgrade the dependencies and remove these suppressions before release.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.trivyignore around lines 8 - 22, Upgrade the bundled Jackson dependencies
referenced by ballerina/LICENSE to at least 2.18.8/2.21.4 and Netty native
transport dependencies to at least 4.1.135.Final/4.2.15.Final, then remove the
corresponding CVE and GHSA entries from .trivyignore so the release scan reports
no suppressed unresolved vulnerabilities.
| if (!bbe.needCentral) { | ||
| additionalParams += " --sticky --offline" | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and inspect the relevant Gradle section and nearby Windows/Unix command construction.
fd -a 'build.gradle' . | sed 's#^\./##' | head -20
echo '--- ballerina/build.gradle lines 920-990 ---'
sed -n '920,990p' ballerina/build.gradle | nl -ba -v920
echo '--- search for additionalParams usage ---'
rg -n "additionalParams|balancedArgs|commandLine|workDir|BalBean|task|doLast" ballerina/build.gradleRepository: ballerina-platform/ballerina-distribution
Length of output: 1123
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- ballerina/build.gradle lines 930-985 ---'
sed -n '930,985p' ballerina/build.gradle | cat -n
echo '--- search for addAdditionalParams/additionalParams/commandLine/workDir ---'
rg -n "addAdditionalParams|additionalParams|commandLine|workDir|Bal|BalBean|winPath|win|Windows" ballerina/build.gradle
echo '--- outline for relevant subprojects/tasks if available ---'
wc -l ballerina/build.gradle
sed -n '880,930p' ballerina/build.gradle | cat -nRepository: ballerina-platform/ballerina-distribution
Length of output: 12957
🌐 Web query:
Gradle ExecSpec commandLine multiple arguments no shell
💡 Result:
Gradle's ExecSpec does not use a shell to execute processes [1]. It invokes the specified executable directly, ensuring that multiple arguments are passed as discrete elements to the process, which avoids common shell-injection and quoting issues [2][3][4]. To provide multiple arguments without a shell, use the following approaches: 1. Using commandLine with multiple arguments: The commandLine method accepts an iterable or a varargs list where the first element is the executable and the subsequent elements are the arguments [2][4]. task runCommand(type: Exec) { // The executable is the first element, followed by individual arguments commandLine 'my-executable', '--arg1', 'value1', '--arg2', 'value2' } 2. Separating the executable and arguments: You can explicitly set the executable and use the args method to append arguments [2][5]. task runCommand(type: Exec) { executable 'my-executable' args '--arg1', 'value1', '--arg2', 'value2' } Because Gradle does not use a shell, you do not need to wrap arguments in quotes to handle spaces or special characters in the same way you would in a shell script [1]. Each argument passed to commandLine or args is treated as a distinct command-line parameter for the underlying process [2][3]. If you specifically need shell features (like pipes or wildcards), you must invoke the shell explicitly as the executable, passing your command string as its arguments (e.g., commandLine 'sh', '-c', 'my-command | grep pattern') [5][1].
Citations:
- 1: exec must support running with the shell, like most programming environments do, when invoking subprocesses gradle/gradle#35687
- 2: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Exec.html
- 3: https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.process/-exec-spec/index.html
- 4: https://docs.gradle.org/current/javadoc/org/gradle/process/ExecSpec.html
- 5: https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.tasks/-exec/index.html
Pass --sticky and --offline as separate Windows arguments.
The Windows path builds one string and passes it as a single cmd /c argument, so bal.bat receives --sticky --offline as one option. Use a list of options for Windows and keep joining only the shell command.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ballerina/build.gradle` around lines 964 - 966, Update the Windows command
construction around the needCentral condition to store --sticky and --offline as
separate option elements, rather than appending them to one argument string.
Pass the options list when invoking bal.bat, and only join the complete command
for the shell execution.
| ballerina-time-2.8.0.jar jar apache2 | ||
| ballerina-ftp-2.15.1.jar jar apache2 | ||
| ballerina-ai.intelligence-1.7.0.jar jar apache2 | ||
| ballerina-ai.observe-1.7.0.jar jar apache2 | ||
| ballerina-ai-1.7.0.jar jar apache2 | ||
| ballerina-lang.future-0.0.0.jar jar apache2 | ||
| ballerina-io-1.8.0.jar jar apache2 | ||
| ballerina-lang.boolean-0.0.0.jar jar apache2 | ||
| ballerina-lang.decimal-0.0.0.jar jar apache2 | ||
| ballerina-avro-1.2.0.jar jar apache2 | ||
| ballerina-lang.function-0.0.0.jar jar apache2 | ||
| ballerina-auth-2.14.0.jar jar apache2 | ||
| ballerina-tcp-1.13.0.jar jar apache2 | ||
| ballerina-tcp-1.13.2.jar jar apache2 | ||
| ballerina-lang.array-0.0.0.jar jar apache2 | ||
| ballerina-lang.string-0.0.0.jar jar apache2 | ||
| ballerina-data.jsondata-1.1.0.jar jar apache2 | ||
| ballerina-data.jsondata-1.1.3.jar jar apache2 | ||
| ballerina-lang.object-0.0.0.jar jar apache2 | ||
| ballerina-lang.transaction-0.0.0.jar jar apache2 | ||
| ballerina-random-1.7.0.jar jar apache2 | ||
| ballerina-lang.typedesc-0.0.0.jar jar apache2 | ||
| ballerina-websocket-2.14.0.jar jar apache2 | ||
| ballerina-websocket-2.15.0.jar jar apache2 | ||
| ballerina-jballerina.java-0.0.0.jar jar apache2 | ||
| ballerina-observe-1.5.0.jar jar apache2 | ||
| ballerina-observe.mockextension-1.5.0.jar jar apache2 | ||
| ballerina-observe-1.6.0.jar jar apache2 | ||
| ballerina-observe.mockextension-1.6.0.jar jar apache2 | ||
| ballerina-uuid-1.10.0.jar jar apache2 | ||
| ballerina-email-2.12.0.jar jar apache2 | ||
| ballerina-task-2.7.0.jar jar apache2 | ||
| ballerina-edi-1.5.0.jar jar apache2 | ||
| ballerina-email-2.13.0.jar jar apache2 | ||
| ballerina-task-2.11.0.jar jar apache2 | ||
| ballerina-edi-1.5.3.jar jar apache2 | ||
| ballerina-lang.query-0.0.0.jar jar apache2 | ||
| ballerina-cloud-3.3.0.jar jar apache2 | ||
| ballerina-url-2.6.0.jar jar apache2 | ||
| ballerina-cloud-4.0.0.jar jar apache2 | ||
| ballerina-url-2.6.1.jar jar apache2 | ||
| ballerina-lang.stream-0.0.0.jar jar apache2 | ||
| ballerina-cache-3.10.0.jar jar apache2 | ||
| ballerina-sql-1.16.0.jar jar apache2 | ||
| ballerina-sql-1.17.1.jar jar apache2 | ||
| ballerina-lang.int-0.0.0.jar jar apache2 | ||
| ballerina-xslt-2.9.0.jar jar apache2 | ||
| ballerina-xslt-2.9.1.jar jar apache2 | ||
| ballerina-lang.error-0.0.0.jar jar apache2 | ||
| ballerina-lang.float-0.0.0.jar jar apache2 | ||
| ballerina-lang.value-0.0.0.jar jar apache2 | ||
| ballerina-data.csv-0.8.0.jar jar apache2 | ||
| ballerina-data.csv-0.8.1.jar jar apache2 | ||
| ballerina-persist-1.6.0.jar jar apache2 | ||
| ballerina-math.vector-1.2.0.jar jar apache2 | ||
| ballerina-lang.runtime-0.0.0.jar jar apache2 | ||
| ballerina-websubhub-1.15.0.jar jar apache2 | ||
| ballerina-data.xmldata-1.3.0.jar jar apache2 | ||
| ballerina-data.xmldata-1.5.2.jar jar apache2 | ||
| ballerina-protobuf.types.any-1.8.0.jar jar apache2 | ||
| ballerina-protobuf-1.8.0.jar jar apache2 | ||
| ballerina-protobuf.types.duration-1.8.0.jar jar apache2 | ||
| ballerina-protobuf.types.timestamp-1.8.0.jar jar apache2 | ||
| ballerina-protobuf.types.wrappers-1.8.0.jar jar apache2 | ||
| ballerina-protobuf.types.empty-1.8.0.jar jar apache2 | ||
| ballerina-protobuf.types.struct-1.8.0.jar jar apache2 | ||
| ballerina-log-2.12.0.jar jar apache2 | ||
| ballerina-jwt-2.15.0.jar jar apache2 | ||
| ballerina-oauth2-2.14.0.jar jar apache2 | ||
| ballerina-log-2.14.0.jar jar apache2 | ||
| ballerina-ai.np-0.5.1.jar jar apache2 | ||
| ballerina-jwt-2.15.1.jar jar apache2 | ||
| ballerina-mcp-1.0.0.jar jar apache2 | ||
| ballerina-oauth2-2.15.0.jar jar apache2 | ||
| ballerina-mime-2.12.0.jar jar apache2 | ||
| ballerina-crypto-2.9.0.jar jar apache2 | ||
| ballerina-crypto-2.9.2.jar jar apache2 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n 'stdlib(Time|DataXmldata|Log|Crypto)Version' gradle.properties
rg -n 'ballerina-(time|data\.xmldata|log|crypto)-' ballerina/LICENSERepository: ballerina-platform/ballerina-distribution
Length of output: 857
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== gradle.properties relevant pins =="
sed -n '1,80p' gradle.properties
echo
echo "== ballerina/LICENSE header/context =="
sed -n '1,240p' ballerina/LICENSE
echo
echo "== build scripts referencing standard library artifacts =="
rg -n 'stdlib(Time|DataXmldata|Log|Crypto)Version|ballerina-(time|data\.xmldata|log|crypto)-|Ballerina|License|license|BUNDLED' -g '*.gradle' -g '*.gradle.kts' -g '*.properties' .Repository: ballerina-platform/ballerina-distribution
Length of output: 49549
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '== LICENSE vs gradle.properties relevant version pins ==\n'
python3 - <<'PY'
from pathlib import Path
import re
props = {}
for line in Path('gradle.properties').read_text().splitlines():
m = re.match(r'([A-Za-z0-9_]+)Version=(.+)', line)
if m:
props[m.group(1)] = m.group(2)
license_text = Path('ballerina/LICENSE').read_text()
for var in ['Time', 'DataXmldata', 'Log', 'Crypto']:
prop = props.get(f'stdlib{var}Version')
jars = re.findall(rf'ballerina-\\b{var}\\b.?[^\\s]+', license_text)
print(f'{var}: gradle.properties {prop}; in ballerina/LICENSE: {jars}' if jars else f'{var}: gradle.properties {prop}; in ballerina/LICENSE: none')
PY
printf '\n== build.gradle stdlib declarations around referenced constants ==\n'
sed -n '120,175p' build.gradle
sed -n '1420,1485p' build.gradle
sed -n '1980,2035p' build.gradleRepository: ballerina-platform/ballerina-distribution
Length of output: 3911
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n 'License|Bundled License|license|GENERATE|generate.*license|jar-file|Jars|JarFile|copyJar|bndJar' build.gradle
rg -n 'License|Bundled License|license|GENERATE|generate.*license|jar-file|Jars|JarFile|copyJar|bndJar' ballerina/build.gradle gradle -g '*.gradle' -g '*.gradle.kts'Repository: ballerina-platform/ballerina-distribution
Length of output: 1983
Regenerate the bundled-license inventory.
ballerina/LICENSE lists older versions for several generated standard-library JARs, while the build resolves newer versions, for example time 2.8.0 vs 2.8.1, xmldata 1.5.2 vs 1.6.3, log 2.14.0 vs 2.17.0, and crypto 2.9.2 vs 2.12.1. Use the generated release artifacts for this inventory so the shipped license notice matches the distribution.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ballerina/LICENSE` around lines 167 - 225, Regenerate the bundled license
inventory in ballerina/LICENSE from the current generated release artifacts
rather than manually retaining stale JAR entries. Update all listed dependency
versions, including ballerina-time, ballerina-data.xmldata, ballerina-log,
ballerina-crypto, and any other resolved artifacts, so the shipped license
notice exactly matches the distribution.
| private log:Level level; | ||
|
|
||
| public isolated function init(string applicationName, string version, log:KeyValues context = {}) { | ||
| public isolated function init(string applicationName, string version, log:KeyValues context = {}, | ||
| log:Level level = log:INFO) { | ||
| self.applicationName = applicationName; | ||
| self.version = version; | ||
| self.context = context.cloneReadOnly(); | ||
| self.level = level; | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate file =="
git ls-files | grep -F 'examples/custom-logger/custom_logger.bal' || true
echo "== file excerpt =="
if [ -f examples/custom-logger/custom_logger.bal ]; then
nl -ba examples/custom-logger/custom_logger.bal | sed -n '1,120p'
fi
echo "== search for logger level APIs in repo examples =="
rg -n "setLevel|getLevel|printInfo|printDebug|printWarn|printError|log:Logger" examples -S || true
echo "== try Ballerina tooling availability =="
command -v bal || true
if command -v bal >/dev/null 2>&1; then
bal --version 2>&1 | head
fiRepository: ballerina-platform/ballerina-distribution
Length of output: 297
🏁 Script executed:
#!/bin/bash
set -u
echo "== file excerpt =="
if [ -f examples/custom-logger/custom_logger.bal ]; then
awk '{ printf "%6d\t%s\n", NR, $0 }' examples/custom-logger/custom_logger.bal | sed -n '1,140p'
fi
echo "== search for logger level APIs in repo examples =="
grep -RInE "setLevel|getLevel|printInfo|printDebug|printWarn|printError|log:Logger" examples 2>/dev/null || true
echo "== Ballerina tooling availability =="
command -v bal || true
if command -v bal >/dev/null 2>&1; then
bal --version 2>&1 | head -n 5
fiRepository: ballerina-platform/ballerina-distribution
Length of output: 29636
🌐 Web query:
Ballerina log module Logger printDebug printWarn printError printInfo setLevel Level semantics
💡 Result:
The Ballerina log module provides a structured way to log application information with configurable levels and formats [1][2]. Log Levels and Semantics The module supports four primary log levels, ordered by priority (from highest to lowest): 1. ERROR: Indicates significant issues requiring immediate attention [1][3]. 2. WARN: Indicates potential issues or unexpected events that are not critical errors [1][3]. 3. INFO: Indicates general operational messages (default level) [1][3]. 4. DEBUG: Indicates detailed information typically useful for diagnosing issues [1][3]. By default, the system logs messages at the INFO level and higher (i.e., INFO, WARN, and ERROR) [1][2]. Logging API Functions The module provides the following functions to log messages at their respective levels: - log:printError(string msg, error? 'error =, *log:KeyValues keyValues): Logs an error, optionally including error details and contextual key-value pairs [1][4]. - log:printWarn(string msg, *log:KeyValues keyValues): Logs a warning message [2][4]. - log:printInfo(string msg, *log:KeyValues keyValues): Logs an informational message [2][4]. - log:printDebug(string msg, *log:KeyValues keyValues): Logs a debug message [2][4]. Configuration Log levels are configured in the Config.toml file [1][2]. You can set the global log level or define specific levels for individual modules [1][4]. Example Config.toml configuration: [ballerina.log] level = "DEBUG" # Or per-module [[ballerina.log.modules]] name = "my_org/my_module" level = "WARN" The log module also supports contextual logging, runtime log level modifications, log rotation, and sensitive data masking [1][2][3]. Logs are written to stderr by default in logfmt format, but this can be modified via configuration to support different destinations and JSON formatting [1][2][4].
Citations:
- 1: https://central.ballerina.io/ballerina/log/latest
- 2: https://github.com/ballerina-platform/module-ballerina-log
- 3: https://ballerina.io/spec/log/
- 4: https://central.ballerina.io/ballerina/log/2.6.0
Make level gate logger output.
level is stored and inherited, but the print methods do not read it. printInfo still calls log:printInfo, and the other levels do not emit. If getLevel()/setLevel() should follow the log:Logger contract, add ordering checks in printInfo, printWarn, printError, and printDebug, and delegate only the enabled levels.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@examples/custom-logger/custom_logger.bal` around lines 10 - 18, Update the
logger print methods to honor the configured level through the existing level
accessor or comparison semantics: add ordering checks in printInfo, printWarn,
printError, and printDebug, and delegate to the corresponding log functions only
when enabled. Ensure all four levels emit appropriately while disabled levels
produce no output, preserving the log:Logger contract for getLevel/setLevel.
Source: MCP tools
| log:Level parentLevel; | ||
| lock { | ||
| // Child loggers inherit the level from the parent logger | ||
| parentLevel = self.level; | ||
| } | ||
| return new ApplicationLogger(self.applicationName, self.version, newContext, parentLevel); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Locate relevant files"
fd -a 'custom_logger.bal|Logger|ApplicationLogger|setLevel|withContext' . | sed 's#^\./##'
echo
echo "File outline/contents for custom_logger.bal"
wc -l examples/custom-logger/custom_logger.bal
cat -n examples/custom-logger/custom_logger.balRepository: ballerina-platform/ballerina-distribution
Length of output: 4321
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Search for logger-related usages/tests"
rg -n "withContext|setLevel|Level|ApplicationLogger|parent|contextual|custom-logger" . || true
echo
echo "Check Ballerina log spec references in repo"
rg -n "log:Level|applicationLogger|withContext|setLevel|Logger" -g '*.md' -g '*.bal' -g '*.toml' . || trueRepository: ballerina-platform/ballerina-distribution
Length of output: 27271
🌐 Web query:
Ballerina log logger withContext setLevel contextual logger getLevel
💡 Result:
In the Ballerina log module, you can manage log levels and contextual logging using the Logger object [1][2]. Contextual Logging and withContext The withContext method is used to create a new, derived Logger instance that includes additional key-value pairs in its context [1][2]. - Child loggers created via withContext do not have their own independent log levels [1][2]. - Instead, they always inherit the effective log level from their parent logger [1][2]. Log Level Management (getLevel and setLevel) The Logger object provides methods to manage log levels at runtime [1][2]: - getLevel(): Returns the effective log:Level of the logger [1][2]. For root or loggers created via fromConfig, this is their explicitly set level [1][2]. For child loggers (created via withContext), this method returns the level inherited from the parent [1][2]. - setLevel(log:Level level): Updates the log level of the logger at runtime [1][2]. - This operation is supported for root loggers and loggers created via fromConfig [1][2]. - Attempting to call setLevel on a child logger (created via withContext) will return an error, as these loggers must always inherit the parent's level [1][2]. To change the effective level of a child logger, you must change the level of the parent logger from which it was derived [1][2]. Loggers created via fromConfig can also be registered and discovered via the logger registry for runtime updates [2].
Citations:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Check for tests around custom_logger example"
fd -a 'custom_logger|custom-log|custom_logger' . | sed 's#^\./##'
echo
echo "Search for appLogger.orderLogger pattern or setLevel test in Ballerina core/source tests"
rg -n "appLogger|orderLogger|ApplicationLogger|setLevel\\(|withContext\\(" -g '*test*' -g '*.bal' -g '*.java' . | head -n200Repository: ballerina-platform/ballerina-distribution
Length of output: 2271
🌐 Web query:
bal langspec Logger withContext getLevel setLevel contextual logger spec
💡 Result:
In the Ballerina language log library, contextual and configurable logging is managed through the log:Logger object [1][2]. Key aspects of the requested API components include: withContext The withContext function is used to create a new child or derived logger that includes additional key-value pairs in its context [1][3]. Signature: public isolated function withContext(*KeyValues keyValues) returns Logger|error; [1] Behavior: Child loggers created via withContext do not have their own independent log level configuration; instead, they always inherit the effective log level from their parent logger [1][2]. getLevel The getLevel function retrieves the effective log level of the logger [1]. Signature: public isolated function getLevel() returns Level; [1] Behavior: For the root logger or custom loggers created via fromConfig, it returns the explicitly set level [1][2]. For child loggers, it delegates to the parent logger's getLevel() [1]. If the parent logger's level changes, the child logger's effective level changes automatically [1]. setLevel The setLevel function allows for modifying the log level of a logger at runtime [1][2]. Signature: public isolated function setLevel(Level level) returns error?; [1] Behavior: This operation is supported on the root logger and custom loggers registered in the logger registry (those created via fromConfig) [1][2]. It is not supported on child loggers (created via withContext), and calling setLevel on a child logger will return an error, as these loggers are designed to strictly inherit from their parent [1][2][4]. In summary, while you can programmatically manage the log levels of primary or custom-configured loggers at runtime, child loggers defined via withContext are designed to maintain consistency with their parent by inheriting its level settings rather than having their own modifiable configurations [1][4].
Citations:
- 1: https://ballerina.io/spec/log/
- 2: https://central.ballerina.io/ballerina/log/latest
- 3: https://github.com/ballerina-platform/module-ballerina-log
- 4: Add native support for modifying the log level programmatically at runtime ballerina-library#6213
🌐 Web query:
https://ballerina.io/spec/log getLevel setLevel contextual logs
💡 Result:
In the Ballerina log module, getLevel() and setLevel() are methods associated with log:Logger instances that allow for the management of log levels [1][2]. Log Levels and Configuration The log module supports four log levels, ordered by priority: ERROR, WARN, INFO, and DEBUG [2][3]. By default, INFO and higher levels are logged [2]. While global and per-module log levels can be configured statically at startup via Config.toml, runtime modifications are possible for loggers created using log:fromConfig [2]. Runtime Level Management Loggers created via log:fromConfig(id = "...", ...) are registered in a central registry [2]. - getLevel: Returns the effective log level of the logger [1]. For root or custom (registered) loggers, this is the explicitly set level [1]. - setLevel(log:Level): Updates the log level of a registered logger at runtime [1][2]. - Registry Access: You can use log:getLoggerRegistry() to discover all registered loggers via their unique IDs and update them programmatically [2]. Contextual Logging The log module supports contextual logging, which allows you to create child (derived) loggers that inherit settings from a parent [1][2]. - Inheritance: Child loggers created via withContext are not independently registered in the logger registry [1][2]. They always inherit their effective log level from their parent logger [1]. - getLevel: Calling getLevel() on a child logger delegates the request to its parent [1]. - setLevel: Attempting to call setLevel() on a child logger will result in an unsupported operation error [1]. To change the effective log level of a child logger, you must change the log level of its parent [1].
Citations:
- 1: https://ballerina.io/spec/log/
- 2: https://central.ballerina.io/ballerina/log/latest
- 3: https://github.com/ballerina-platform/module-ballerina-log
Preserve dynamic level inheritance for contextual loggers.
withContext currently copies self.level, so later parent setLevel() calls do not update the child. Child logger setLevel() also succeeds instead of returning an unsupported-operation error. Keep the child bound to the parent level from the Ballerina log API, and add a test that changes the parent level after creating the child.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@examples/custom-logger/custom_logger.bal` around lines 64 - 69, Update
withContext so the contextual logger retains the parent logger’s dynamic level
binding instead of copying self.level, and ensure child setLevel returns the log
API’s unsupported-operation error. Add a test that creates a child, changes the
parent level afterward, and verifies the child reflects the updated level.
Source: MCP tools
ballerina/data.xmldataand current conversion APIs.