# Demo Case: Java with DolphinScheduler - Log4Shell
Show how Gomboc can take a real, actively maintained open-source Java project and go from "find problems" to "find and fix" directly in your IDE, then package the changes into a clean PR that your tea
You'll use a real-world open-source project ([Apache DolphinScheduler](https://github.com/apache/dolphinscheduler)) with Maven to demonstrate a Log4j 1.x vulnerability remediation, replacing the `slf4j-log4j12` binding (which pulls in the end-of-life `log4j:log4j` 1.x library) with the patched `slf4j-reload4j` drop-in replacement.
#### Prerequisites
* Gomboc IDE plugin installed and configured. See: [VSCode Plugin page](https://docs.gomboc.ai/getting-started-ce/gomboc-demo-cases/pages/XleNum4pRoxI8RQkj5w7#id-0.-prerequisites).
* Java / Maven installed locally (if you plan to run build validation)
#### Step 0: Prepare the demo repo
1. Clone the demo repo and open it in VS Code:
```bash
git clone https://github.com/iac-playground/dolphinscheduler.git
```
2. Confirm the repo contains the vulnerable dependency. Open `pom.xml` and look for:
```xml
1.7.5
```
and the corresponding dependency:
```xml
org.slf4jslf4j-log4j12${slf4j.log4j12.version}
```
This dependency transitively pulls in `log4j:log4j` 1.x, which is end-of-life and has critical CVEs (CVE-2019-17571, CVE-2021-4104, CVE-2022-23302/23305/23307).
#### Step 1: Run the first scan
1. Open the Command Palette (`Ctrl/Cmd + Shift + P`)
2. Run: Gomboc: Scan current file or scenario (or scan-on-save, if enabled)
3. Keep the repo open: Gomboc will scan all XML files in the project and identify the vulnerable `slf4j-log4j12` dependency.
{% hint style="info" %}
Traditional tools mostly stop at "here are findings." Gomboc is built to connect findings to fixes in a consistent, reviewable workflow.
{% endhint %}
#### Step 2: Review findings
In the IDE results list, you should see a finding for the `slf4j-log4j12` dependency. The finding will indicate:
* **What:** `org.slf4j:slf4j-log4j12` dependency detected in `pom.xml`
* **Why:** Transitively pulls in log4j 1.x (EOL) with critical vulnerabilities
* **Fix:** Replace with `org.slf4j:slf4j-reload4j:1.7.36`, a maintained, binary-compatible drop-in replacement
You can also review this through the Gomboc Reviewer (Webview), which will provide you a single, centralized place to triage the findings, preview deterministic remediations, and apply changes across multiple files.
1. In the Gomboc results list, select the **slf4j-log4j12** finding.
2. Click **Review in Webview**
* This opens a Gomboc "web view" inside the IDE that's optimized for reviewing fixes.
#### Step 3: Inspect finding details
For the selected finding in the Webview Reviewer, review:
1. **Resource reference** (which `pom.xml` and dependency block is affected)
2. **Rule / policy driver** (the Log4j 1.x migration rule that triggered this fix)
3. **Description** of what the fix does, replaces `slf4j-log4j12` with `slf4j-reload4j`
4. (Optional) **External mapping** fields if present
#### Step 4: Preview fixes
1. In the Webview Reviewer, click **Preview** (or **Preview fixes**).
2. Gomboc will:
* apply the changes in the correct order
* ensure changes are consistent across dependencies
* generate a preview of code diffs you can review before applying
3. Wait for preview generation to complete.
**What you should see:**
* A preview showing two **exact code changes** in the `` block:
* `slf4j-log4j12` → `slf4j-reload4j`
* `${slf4j.log4j12.version}` → `1.7.36`
* A concrete diff, not just a recommendation.
#### Step 5: Review diffs in detail
For the previewed fix:
1. Click **Open diff** to see the exact Maven dependency patch.
2. Use **View full resource in context** to understand how the change fits into the `pom.xml`.
3. Confirm the fix is:
* logically correct, `slf4j-reload4j` is a binary-compatible replacement
* consistent with your organization's expectations
* not introducing unexpected side effects (the orphaned `` property is harmless dead config)
#### Step 6: Apply fixes from the Webview Reviewer
1. After reviewing preview diffs, click **Apply** (or **Apply fixes**).
2. Gomboc will apply the patch to your working tree.
#### Step 7: Validate changes locally (recommended)
In a terminal at the repo root:
1. Verify the dependency change:
* Open `pom.xml` and confirm `slf4j-log4j12` has been replaced with `slf4j-reload4j` at version `1.7.36`
2. (Optional) Build:
* `mvn compile` or `mvn validate`\
(the DolphinScheduler build may require additional setup, the dependency change itself is safe regardless)
**Checkpoint:** The `pom.xml` now references `slf4j-reload4j:1.7.36` instead of `slf4j-log4j12`.
#### Step 8: Re-scan to confirm findings are resolved
1. Run the scan again from the IDE:
* **Scan** → **Scan current file or scenario**
2. Confirm the `slf4j-log4j12` finding is now:
* resolved / removed
* the scan returns zero findings for this rule
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.gomboc.ai/getting-started-ce/gomboc-demo-cases/demo-case-java-with-dolphinscheduler-log4shell.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.