Skip to content

Conversation

@shawn-hurley
Copy link
Contributor

@shawn-hurley shawn-hurley commented Oct 24, 2025

  • Phase 1 adds unit tests for parsing and validation of the input to the handler.
  • Phase 2 adds a Go JSON RPC client to run a set of integration tests against test projects to verify the accuracy of results.
  • The testing infrastructure was also added to use the phases to validate any changes on PR or merge.
  • README.md in java-analyzer-bundle.test/integration/ to document the testing.

Summary by CodeRabbit

  • New Features

    • Enhanced symbol searches: enum-constant & package declaration support, improved return-type and parameterized-type matching.
  • Tests

    • Full test suite added: Phase 1 unit tests and Phase 2 containerized Go integration tests covering all 15 location types, annotation queries, and file-path filtering.
  • Documentation

    • Comprehensive test docs, quick reference, query reference, and guides for running tests locally and in CI.
  • Chores

    • CI workflow, local Makefile, container build/run scripts and test-ready container image added.

@coderabbitai
Copy link

coderabbitai bot commented Oct 24, 2025

Walkthrough

Adds a two‑phase CI/local pipeline and container test image, a Go-based JDT.LS integration test framework, many Java symbol-provider enhancements and new providers, two test projects with fixtures, extensive unit/integration tests, updated Dockerfiles/Makefile, and comprehensive test documentation.

Changes

Cohort / File(s) Summary
CI/CD & Local Orchestration
​.github/workflows/integration-tests.yml, Makefile, java-analyzer-bundle.test/integration/run_local.sh
Add GitHub Actions workflow (Phase1 unit tests, Phase2 JDT.LS integration), a Makefile mirroring CI with Podman/Docker detection and composite targets, and a shell script to run Phase2 locally in a container.
Go Integration Framework
java-analyzer-bundle.test/integration/jdtls_client.go, java-analyzer-bundle.test/integration/go.mod, java-analyzer-bundle.test/integration/integration_test.go, java-analyzer-bundle.test/integration/test_helpers.go
Add Go JDT.LS client (process lifecycle, JSON-RPC binder/dialer), SearchSymbols APIs with annotation query support, integration test suite covering all location types, and test helper utilities.
Container Images & Dockerfiles
Dockerfile, Dockerfile.test
Adjust Dockerfile plugin JAR copy locations and JAVA_HOME handling; add a new multi-stage Dockerfile.test that prepares a runtime image with JDT.LS, fernflower, Maven/JDKs, and maven-index artifacts.
Make / Local Helpers
run_local.sh, Makefile
Build and run containerized integration tests locally, detect runtime, mount repo, set env vars, and forward exit code.
Symbol Search Core Changes
java-analyzer-bundle.core/.../SampleDelegateCommandHandler.java, .../SymbolInformationTypeRequestor.java, .../symbol/CustomASTVisitor.java, .../symbol/ConstructorCallSymbolProvider.java, .../symbol/ReturnTypeSymbolProvider.java, .../symbol/VariableDeclarationSymbolProvider.java
Add erasure-aware matching, regex handling, extended search pattern use, improved AST fallbacks and element discovery, enhanced logging/diagnostics, and thread SearchPattern through the requestor API (constructor signature changed).
New Symbol Providers & Resolver Updates
java-analyzer-bundle.core/.../symbol/EnumConstantSymbolProvider.java, .../PackageDeclarationSymbolProvider.java, .../SymbolProviderResolver.java
Add EnumConstantSymbolProvider and PackageDeclarationSymbolProvider; update resolver mappings (location 6 → enum constants, location 11 → package declarations).
Java Test Projects: customers-tomcat-legacy
java-analyzer-bundle.test/projects/customers-tomcat-legacy/...
Add a WAR sample: pom.xml, Dockerfile, Makefile, Spring config/classes (controllers, services, repos, entities), persistence properties, import.sql seed, .gitignore and supporting files for migration-style integration tests.
Java Test Projects: test-project
java-analyzer-bundle.test/projects/test-project/...
Add a lightweight test project with many Java fixtures (Calculator, SampleApplication, servlets, annotations, JMS/persistence classes, Eclipse metadata, pom) to exercise all search locations.
Java Unit & Integration Tests
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/{RuleEntryParamsTest,SampleDelegateCommandHandlerTest}, java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java, java-analyzer-bundle.test/integration/*.go
Add/expand unit tests for RuleEntryParams and AnnotationQuery; expand SampleDelegateCommandHandlerTest with many location/mode cases; add Go integration tests validating symbol results and annotation matching.
Build & Coverage
pom.xml
Update coverage.filter to io.konveyor.tackle.*, disable Tycho UI harness, and add JaCoCo prepare-agent and report executions.
Docs & Guides
java-analyzer-bundle.test/README.md, java-analyzer-bundle.test/docs/{README.md,integration-tests.md,query-reference.md,quick-reference.md,test-projects.md}
Add comprehensive test/docs describing architecture, running phases, coverage matrix (15/15 locations), how to add tests, and troubleshooting.
Project Metadata & IDE files
.gitignore, java-analyzer-bundle.test/projects/*/.project, .../.settings/*
Add Eclipse .project/.classpath/.settings and ignore rules for test projects and workspace metadata.

Sequence Diagram(s)

sequenceDiagram
    participant GH as GitHub Actions
    participant Phase1 as Phase 1 (Unit Tests)
    participant Maven as Maven
    participant Phase2 as Phase 2 (Integration)
    participant Builder as Image Build
    participant Container as Container Runtime
    participant JDTLS as JDT.LS
    participant GoT as Go Tests

    GH->>Phase1: push/PR triggers
    Phase1->>Maven: mvn clean integration-test
    Maven-->>Phase1: surefire reports
    Phase1-->>GH: Phase1 complete

    GH->>Phase2: continue
    Phase2->>Builder: build Dockerfile.test
    Builder-->>Phase2: image
    Phase2->>Container: run image (Podman/Docker)
    Container->>JDTLS: launch server
    Container->>GoT: run go test
    GoT->>JDTLS: executeCommand / symbol searches
    JDTLS-->>GoT: symbol results
    GoT-->>Container: test exit code
    Container-->>Phase2: results
    Phase2-->>GH: Phase2 complete
Loading
sequenceDiagram
    participant GoClient as Go JDTLS client
    participant Dialer as CmdDialer
    participant JDTLS as JDT.LS process
    participant RPC as JSON-RPC

    GoClient->>Dialer: create pipes
    GoClient->>JDTLS: start process (cmd)
    JDTLS-->>Dialer: stdout/stdin
    GoClient->>RPC: connect over Dialer (jsonrpc2)
    RPC-->>GoClient: connection established
    GoClient->>JDTLS: initialize LSP (initialize/initialized)
    JDTLS-->>RPC: initialize result
    GoClient->>JDTLS: executeCommand (search) / workspace calls
    JDTLS-->>RPC: symbol results
    GoClient->>JDTLS: shutdown/exit
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45–75 minutes

  • Heterogeneous changes: CI/docker infra, Go integration client and tests, Java core search logic and many new Java fixtures.
  • Files needing extra attention:
    • java-analyzer-bundle.test/integration/jdtls_client.go — process I/O, JSON-RPC binder/dialer, timeouts.
    • java-analyzer-bundle.core/.../ConstructorCallSymbolProvider.java, VariableDeclarationSymbolProvider.java, CustomASTVisitor.java — AST parsing, erasure handling, regex matching.
    • java-analyzer-bundle.core/.../SymbolInformationTypeRequestor.java — constructor signature change and call sites.
    • Dockerfile.test and container artifact-stage handling and final runtime setup.
    • java-analyzer-bundle.test/integration/integration_test.go — environment assumptions and assertions.

Possibly related PRs

Suggested reviewers

  • jmle

Poem

🐰 A Rabbit's Ode to Tests
Hop through containers, logs that gleam,
Go talks to JDT.LS in a dream,
Fifteen searches, each a beam,
Builds and docs in tidy stream,
I nibble bugs — then celebrate with cream! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 26.02% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main objective: adding a comprehensive integration test suite with CI/CD pipeline. It is specific, clear, and directly summarizes the primary changes.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b59ec94 and 5c0db6c.

📒 Files selected for processing (1)
  • Dockerfile (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • Dockerfile
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: JDT.LS Integration Tests (Phase 2)
  • GitHub Check: Build tackle2-addon-analyzer

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 22

♻️ Duplicate comments (5)
java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/3a/f0329fb788b00010150f900a41fc8a5f (1)

1-3: Same nested metadata structure issue.

See the comment on file .../history/6e/c0bd9eb788b00010150f900a41fc8a5f regarding the nested .metadata/.metadata/ path structure.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/ca/20a89fb788b00010150f900a41fc8a5f (1)

1-4: Same nested metadata structure issue.

See the comment on file .../history/6e/c0bd9eb788b00010150f900a41fc8a5f regarding the nested .metadata/.metadata/ path structure.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/3f/a0e0a0b788b00010150f900a41fc8a5f (1)

1-6: Same nested metadata structure issue.

See the comment on file .../history/6e/c0bd9eb788b00010150f900a41fc8a5f regarding the nested .metadata/.metadata/ path structure.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/d1/507ad5b688b00010150f900a41fc8a5f (1)

1-8: Same nested metadata structure issue.

See the comment on file .../history/6e/c0bd9eb788b00010150f900a41fc8a5f regarding the nested .metadata/.metadata/ path structure.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/21/b0bec7b688b00010150f900a41fc8a5f (1)

1-5: Same nested metadata structure issue.

See the comment on file .../history/6e/c0bd9eb788b00010150f900a41fc8a5f regarding the nested .metadata/.metadata/ path structure.

🧹 Nitpick comments (34)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1)

1-21: LGTM! Clean test exception implementation.

The custom exception follows standard Java patterns with proper serialVersionUID and delegates to superclass constructors appropriately. For a test file focused on inheritance detection, this implementation is well-suited.

Optionally, consider adding the fourth common constructor pattern public CustomException(Throwable cause) for completeness, though it's not essential for the testing purpose.

Optional: Add fourth constructor pattern
     public CustomException(String message, Throwable cause) {
         super(message, cause);
     }
+
+    public CustomException(Throwable cause) {
+        super(cause);
+    }
 }
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1)

8-10: Consider removing redundant modifiers and fixing spacing.

Interface methods are implicitly public in Java, so the public keyword is redundant. Additionally, line 10 is missing a space between > and findAll.

Apply this diff to improve code style:

-    public Customer findById(Long id); 
+    Customer findById(Long id);
 	
-	public Page<Customer>findAll(Pageable pageable);
+	Page<Customer> findAll(Pageable pageable);
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1)

28-35: Consider using Optional for null safety.

The method returns null when no matching code is found, which could lead to NPEs in calling code. Consider returning Optional<EnumExample> instead.

Apply this diff:

-    public static EnumExample fromCode(int code) {
+    public static Optional<EnumExample> fromCode(int code) {
         for (EnumExample e : values()) {
             if (e.code == code) {
-                return e;
+                return Optional.of(e);
             }
         }
-        return null;
+        return Optional.empty();
     }

Add the import at the top of the file:

import java.util.Optional;
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties (1)

2-4: Externalize database connection details.

The JDBC URL contains a hardcoded IP address and the credentials are hardcoded. While this is a test project, consider externalizing these values to environment variables or a separate configuration file to make the tests more portable and maintainable.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1)

17-18: Consider constructor injection for better testability.

While field injection works, constructor injection is the recommended approach for dependency injection as it makes dependencies explicit, supports immutability, and facilitates testing. However, if this legacy pattern is intentional for testing the analyzer's handling of field injection, this can be deferred.

Apply this diff to use constructor injection:

-	@Autowired
-	private CustomerRepository repository;
+	private final CustomerRepository repository;
+	
+	@Autowired
+	public CustomerService(CustomerRepository repository) {
+		this.repository = repository;
+	}
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1)

11-97: Consider implementing equals() and hashCode() for JPA entity.

JPA entities should typically implement equals() and hashCode() methods to ensure proper entity comparison, especially when entities are used in collections or compared across persistence contexts. Without these methods, entity equality is based on object identity rather than business identity.

For a JPA entity, consider implementing these methods based on the business key (id in this case):

@Override
public boolean equals(Object o) {
	if (this == o) return true;
	if (!(o instanceof Customer)) return false;
	Customer customer = (Customer) o;
	return id != null && id.equals(customer.id);
}

@Override
public int hashCode() {
	return getClass().hashCode();
}

Note: Using getClass().hashCode() for the hashCode implementation ensures consistency across proxy instances and prevents issues when the entity hasn't been persisted yet.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (3)

6-6: Remove unused import.

The fail import is not used anywhere in the test class.

Apply this diff:

-import static org.junit.Assert.fail;

48-61: Strengthen test assertions to verify actual behavior.

Most of these integration tests only assert that the result is not null, which provides minimal verification of correctness. Integration tests should validate:

  • Expected result count (e.g., assertTrue(result.size() > 0) or specific counts)
  • Presence of specific expected symbols in results
  • Result structure and content accuracy

For example, testRuleEntryWithMethodCallLocation could verify that results contain println method calls, or testRuleEntryWithImportLocation could verify specific import statements are found.

Consider strengthening at least a subset of these tests to verify actual search behavior rather than just non-null responses.

Also applies to: 63-76, 78-91, 93-105, 107-120, 122-135, 137-150, 152-169, 191-204, 206-219, 221-234, 236-249


48-61: Consolidate or differentiate duplicate test coverage.

Both testRuleEntryWithFullMode (lines 48-61) and testRuleEntryWithWildcardQuery (lines 176-189) test identical parameters:

  • query: "java.io.*"
  • location: "10"
  • project: "test-project"

The only difference is analysisMode: "full" vs "source-only". Consider:

  1. Renaming tests to clarify they're testing different analysis modes with the same query, or
  2. Using distinct queries to provide broader test coverage

Also applies to: 176-189

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (4)

3-8: Align on JUnit version and prefer assertThrows over @test(expected).

If the repo is on JUnit 5, migrate to Jupiter (org.junit.jupiter.api.*) and use assertThrows. If staying on JUnit 4, target 4.13+ and replace @test(expected=...) for clearer scope and message checks.

Example (JUnit 4.13+):

-@Test(expected = NumberFormatException.class)
-public void testInvalidLocationFormat() {
-  ...
-  new RuleEntryParams("test-command", arguments);
-}
+@Test
+public void testInvalidLocationFormat() {
+  assertThrows(NumberFormatException.class, () -> new RuleEntryParams("test-command", arguments));
+}

Confirm which JUnit is configured in the build before changing.

Also applies to: 15-15


156-173: Add negative/out-of-range location tests to lock the contract.

You validate 0–14; add explicit tests for invalid values (e.g., -1, 99, null/empty) to ensure the API rejects them as intended (exception type/message).


176-200: Strengthen assertions for annotation elements.

This only checks type. Add assertions that elements are parsed (count, name/value), or document that elements are ignored if that’s the contract.

Would you like me to propose assertions once the RuleEntryParams.getAnnotationQuery() API for elements is confirmed?


19-74: Reduce setup duplication with a small helper.

Repeated Map/List plumbing obscures intent. Extract a helper that builds base params, then override per test. Keeps tests terse and readable.

Example helper:

private static Map<String,Object> baseParams(String project, String query, String location, String analysisMode) {
  Map<String,Object> m = new HashMap<>();
  m.put("project", project);
  m.put("query", query);
  m.put("location", location);
  m.put("analysisMode", analysisMode);
  return m;
}

Also applies to: 76-154, 156-250

java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs (1)

1-4: Verify that IDE-specific project settings are necessary.

Eclipse project .settings files are IDE-specific and may cause inconsistencies across different development environments and CI/CD pipelines. The resolveWorkspaceProjects=true setting (Line 3) in particular assumes an Eclipse workspace structure that may not exist in containerized test environments.

If these settings are required for local development, consider documenting the Eclipse setup requirements. Otherwise, these files could be excluded from version control.

java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs (1)

1-3: Consider configuring encoding in the build tool instead.

While UTF-8 encoding is correct, IDE-specific settings may not be respected in CI/CD environments or by developers using different IDEs. Consider setting the encoding explicitly in the Maven pom.xml to ensure consistency:

<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

This ensures UTF-8 encoding is enforced across all build environments, not just Eclipse.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1)

1-26: LGTM! Well-structured multi-stage build.

The Dockerfile follows best practices with a multi-stage build pattern that separates the build and runtime environments, reducing the final image size. The dependency caching layer (line 11) optimizes build times, and the --chown=1001:0 flag (line 23) ensures OpenShift compatibility.

Consider removing the commented-out lines (4 and 20) if the JDK 8 versions are no longer needed for reference:

-# FROM maven:3.6-jdk-8-slim as build
 FROM maven:3.8-openjdk-11 as build
-# FROM tomcat:9-jdk8-openjdk-slim
 FROM tomcat:9-jdk11-openjdk-slim
java-analyzer-bundle.test/projects/README.md (1)

17-25: Add language specifiers to fenced code blocks.

The directory structure code blocks are missing language specifiers, which markdown linters flag. While this doesn't affect functionality, it improves markdown compliance and can enhance rendering in some viewers.

Apply this pattern to both directory structure blocks:

-```
+```text
 io.konveyor.demo/
 ├── annotations/          - Custom annotations
 ...


Also applies to: 62-80

</blockquote></details>
<details>
<summary>java-analyzer-bundle.test/integration/run_local.sh (2)</summary><blockquote>

`4-4`: **Harden the shell options**

Use stricter bash flags to fail fast and catch unset vars/pipe errors.


```diff
-set -e
+set -Eeuo pipefail

37-45: Avoid installing Go on every test run; pre-bake it in the image

Installing Go with microdnf for each run adds minutes and network flakiness. Bake Go into jdtls-analyzer:test (or a builder stage) and drop the runtime install.

   jdtls-analyzer:test \
-  -c "microdnf install -y golang && go mod download && go test -v"
+  -c "go mod download && go test -v"

If pre-baking isn’t feasible, at least mount a Go module cache to speed downloads:

 $CONTAINER_RUNTIME run --rm \
-  -v "$REPO_ROOT/java-analyzer-bundle.test:/tests${VOLUME_FLAGS}" \
+  -v "$REPO_ROOT/java-analyzer-bundle.test:/tests${VOLUME_FLAGS}" \
+  -v "$HOME/.cache/gomod:/root/go/pkg/mod${VOLUME_FLAGS}" \
   -e WORKSPACE_DIR=/tests/projects \
   -e JDTLS_PATH=/jdtls \
.github/workflows/integration-tests.yml (3)

43-47: Remove redundant setup-go; Go runs inside the container

This step doesn’t affect the container. Drop it to save time or move tests outside the container if you intend to use the runner’s Go toolchain.

-      - name: Set up Go
-        uses: actions/setup-go@v5
-        with:
-          go-version: '1.23.9'
+      # Go is provided inside the container image used below

58-71: Pre-bake Go in the image or mount a module cache for stability and speed

Installing Go via microdnf at runtime is slow and flaky. Prefer baking Go into jdtls-analyzer:test and drop the install. If you must install at runtime, mount a cache to reuse modules.

Example (pre-baked Go; no install at runtime):

-            -c "microdnf install -y golang && cd /tests/integration && go mod download && go test -v"
+            -c "cd /tests/integration && go mod download && go test -v"

Optional module cache mount:

-          podman run --rm \
+          podman run --rm \
+            -v "${HOME}/.cache/gomod:/root/go/pkg/mod:Z" \

23-25: Use non-interactive Maven flags for CI

Avoids superfluous output and toolchain downloads.

-        run: mvn clean integration-test
+        run: mvn -B -ntp clean integration-test
java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (4)

9-14: Declare 'all' as PHONY

Silences checkmake warning and prevents unintended file target collisions.

-.PHONY: help
+.PHONY: all help

20-21: Use -f flag for prune instead of echoing to stdin

More reliable and clearer.

-	echo Y | docker image prune
+	docker image prune -f

28-31: Fix target description; it runs a container, not a vagrant VM

Avoids confusion for users.

-run:	## Run a vagrant VM using this image
+run:	## Run a container from the built image

35-37: Make remove idempotent

Don’t fail if images don’t exist; force-remove or ignore errors.

-	docker rmi $(REMOTE_IMAGE_NAME)
-	docker rmi $(LOCAL_IMAGE_NAME)
+	-docker rmi -f $(REMOTE_IMAGE_NAME)
+	-docker rmi -f $(LOCAL_IMAGE_NAME)
java-analyzer-bundle.test/integration/README.md (4)

17-46: Add a language specifier to fenced block to satisfy markdownlint (MD040)

Use text for ASCII diagrams.

-```
+```text
 ┌─────────────────────────────────────────────────────────┐
 ...

---

`384-384`: **Hyphenate “5-second”**

Minor grammar fix.


```diff
-1. **Project not loaded**: JDT.LS needs time to index projects (5 second wait in Initialize())
+1. **Project not loaded**: JDT.LS needs time to index projects (5-second wait in Initialize())

107-118: Align helper names and file path with the code

The code defines unexported helpers in integration/test_helpers.go. Update docs to match.

-### 3. `test_helpers.go`
-Helper functions for result verification.
+### 3. `test_helpers.go`
+Helper functions for result verification (package-local).

-**Key Functions**:
+**Key functions** (as implemented):
 ```go
-func verifySymbolInResults(symbols []protocol.SymbolInformation, expectedName string,
-    expectedKind ...protocol.SymbolKind) bool
+func verifySymbolInResults(symbols []protocol.SymbolInformation, expectedName string, expectedKind ...protocol.SymbolKind) bool

-func verifySymbolLocationContains(symbols []protocol.SymbolInformation,
-    expectedName, expectedFile string) bool
+func verifySymbolLocationContains(symbols []protocol.SymbolInformation, expectedName, expectedFile string) bool

---

`277-306`: **Fix helper reference path and exported names in examples**

Examples mention tests/test_utils.go and exported helpers; update to integration/test_helpers.go and unexported names to match the code.


```diff
-Tests verify using helper functions from `tests/test_utils.go`:
+Tests verify using helper functions from `integration/test_helpers.go`:
@@
-   if VerifySymbolInResults(symbols, "SampleApplication") {
+   if verifySymbolInResults(symbols, "SampleApplication") {
@@
-   if VerifySymbolInResults(symbols, "Customer", protocol.Class) {
+   if verifySymbolInResults(symbols, "Customer", protocol.Class) {
@@
-   if VerifySymbolLocationContains(symbols, "Customer", "Customer.java") {
+   if verifySymbolLocationContains(symbols, "Customer", "Customer.java") {
java-analyzer-bundle.test/integration/integration_test.go (1)

26-33: Consider defaulting WORKSPACE_DIR to /tests/projects for parity with CI

Keeps local defaults consistent with run_local.sh and the workflow.

-    workspaceDir := os.Getenv("WORKSPACE_DIR")
-    if workspaceDir == "" {
-        workspaceDir = "/workspace"
-    }
+    workspaceDir := os.Getenv("WORKSPACE_DIR")
+    if workspaceDir == "" {
+        workspaceDir = "/tests/projects"
+    }
java-analyzer-bundle.test/integration/client/jdtls_client.go (3)

53-58: Don’t kill the process in CmdDialer.Close; let Shutdown manage lifecycle

Killing here can race against graceful shutdown and cause noisy exits. Close pipes and return.

 func (rwc *CmdDialer) Close() error {
-    if rwc.Cmd.Process != nil {
-        rwc.Cmd.Process.Kill()
-    }
-    return rwc.Cmd.Wait()
+    if rwc.Stdin != nil {
+        _ = rwc.Stdin.Close()
+    }
+    if rwc.Stdout != nil {
+        _ = rwc.Stdout.Close()
+    }
+    // Let Shutdown() signal and wait/kill with timeout.
+    return nil
 }

187-193: Avoid hard-coding the bundle jar/version; make it configurable or discoverable

Hard-coded SNAPSHOT path is brittle. Support env/config or glob to locate the bundle.

-        InitializationOptions: map[string]interface{}{
-            "bundles": []string{
-                "/jdtls/plugins/java-analyzer-bundle.core-1.0.0-SNAPSHOT.jar",
-            },
-            "workspaceFolders": []string{string(workspaceURI)},
-        },
+        InitializationOptions: map[string]interface{}{
+            "bundles": discoverBundles(os.Getenv("BUNDLE_JARS"), "/jdtls/plugins/java-analyzer-bundle.core-*.jar"),
+            "workspaceFolders": []string{string(workspaceURI)},
+        },

Add helper (same file):

func discoverBundles(env, pattern string) []string {
    if env != "" {
        return strings.Split(env, ",")
    }
    matches, _ := filepath.Glob(pattern)
    return matches
}

208-211: Replace fixed sleep with a bounded readiness wait

A fixed 5s can be flaky on CI. Poll a lightweight request until the server responds or a timeout elapses.

-    // Wait for server to process projects
-    time.Sleep(5 * time.Second)
+    // Wait (bounded) for server to process projects
+    deadline := time.Now().Add(30 * time.Second)
+    for time.Now().Before(deadline) {
+        var ping interface{}
+        if err := c.conn.Call(c.ctx, "workspace/workspaceFolders", nil).Await(c.ctx, &ping); err == nil {
+            break
+        }
+        time.Sleep(500 * time.Millisecond)
+    }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 23857f4 and 3f70d1f.

⛔ Files ignored due to path filters (8)
  • java-analyzer-bundle.test/integration/go.sum is excluded by !**/*.sum
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.projects/customers-tomcat/.markers.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.projects/customers-tomcat/.syncinfo.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.projects/test-project/.markers.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.projects/test-project/.syncinfo.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.root/.markers.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/0.snap is excluded by !**/*.snap
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.core/variablesAndContainers.dat is excluded by !**/*.dat
📒 Files selected for processing (72)
  • .github/workflows/integration-tests.yml (1 hunks)
  • Dockerfile (2 hunks)
  • Makefile (1 hunks)
  • java-analyzer-bundle.test/integration/README.md (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
  • java-analyzer-bundle.test/integration/go.mod (1 hunks)
  • java-analyzer-bundle.test/integration/integration_test.go (1 hunks)
  • java-analyzer-bundle.test/integration/run_local.sh (1 hunks)
  • java-analyzer-bundle.test/integration/test_helpers.go (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/1a/b04dc5b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/21/b0bec7b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/3a/f0329fb788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/3f/a0e0a0b788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/47/c056cab688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/48/c04c9cb788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/69/10c7c3b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/6b/e093b2b788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/6e/c0bd9eb788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/b0/6044a0b788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/b1/a0f1b8b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/be/3086c6b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/c5/d0d7bbb688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/ca/20a89fb788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/cd/d055a1b788b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/d/401ec9b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/d1/507ad5b688b00010150f900a41fc8a5f (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.launching.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.m2e.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.core/javaLikeNames.txt (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.launching/.install.xml (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.launching/libraryInfos.xml (1 hunks)
  • java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.m2e.core/workspacestate.properties (1 hunks)
  • java-analyzer-bundle.test/projects/README.md (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.classpath (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.project (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1 hunks)
  • pom.xml (3 hunks)
🧰 Additional context used
🧬 Code graph analysis (6)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQuery.java (1)
  • AnnotationQuery (11-75)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)
  • BaseService (9-39)
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (1)
  • SampleDelegateCommandHandler (43-419)
java-analyzer-bundle.test/integration/integration_test.go (1)
java-analyzer-bundle.test/integration/client/jdtls_client.go (2)
  • JDTLSClient (19-28)
  • NewJDTLSClient (82-91)
🪛 actionlint (1.7.8)
.github/workflows/integration-tests.yml

63-63: shellcheck reported issue in this script: SC2046:warning:2:6: Quote this to prevent word splitting

(shellcheck)

🪛 checkmake (0.2.2)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile

[warning] 38-38: Missing required phony target "all"

(minphony)


[warning] 38-38: Missing required phony target "test"

(minphony)


[warning] 9-9: Target "all" should be declared PHONY.

(phonydeclared)

Makefile

[warning] 25-25: Target body for "help" exceeds allowed length of 5 (24).

(maxbodylength)


[warning] 115-115: Target body for "clean" exceeds allowed length of 5 (6).

(maxbodylength)

🪛 LanguageTool
java-analyzer-bundle.test/integration/README.md

[grammar] ~384-~384: Use a hyphen to join words.
Context: ...: JDT.LS needs time to index projects (5 second wait in Initialize()) 2. **Build ...

(QB_NEW_EN_HYPHEN)

🪛 markdownlint-cli2 (0.18.1)
java-analyzer-bundle.test/integration/README.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


62-62: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/projects/README.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


62-62: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🪛 OSV Scanner (2.2.3)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml

[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: QOS.ch Logback vulnerable to Deserialization of Untrusted Data

(GHSA-vmfg-rjjm-rjrj)


[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: logback serialization vulnerability

(GHSA-vmq6-5m68-f53m)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: org.postgresql:postgresql vulnerable to SQL Injection via line comment generation

(GHSA-24rp-q3w6-vc56)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: TemporaryFolder on unix-like systems does not limit access to created files

(GHSA-562r-vg33-8x8h)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Arbitrary File Write Vulnerability

(GHSA-673j-qm5f-xpv8)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: Path traversal in org.postgresql:postgresql

(GHSA-727h-hrw8-jg8q)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names

(GHSA-r38f-c4h4-hqq2)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Does Not Check Class Instantiation when providing Plugin Classes

(GHSA-v7wg-cpwc-24m4)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DoS via conditional HTTP request

(GHSA-2rmj-mq67-h97g)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation

(GHSA-2wrp-6fg6-hmc5)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DataBinder Case Sensitive Match Exception

(GHSA-4gc7-5j7h-4qph)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Pivotal Spring Framework contains unsafe Java deserialization methods

(GHSA-4wrc-f8pq-fpqp)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Web vulnerable to Open Redirect or Server Side Request Forgery

(GHSA-ccgv-vj62-xf9h)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation Vulnerability

(GHSA-hgjh-9rj2-g67j)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Remote Code Execution in Spring Framework

(GHSA-36p3-wjmg-h94x)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework is vulnerable to security bypass via mvcRequestMatcher pattern mismatch

(GHSA-7phw-cxx7-q9vq)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Path traversal vulnerability in functional web frameworks

(GHSA-cx7f-g6mp-7hqm)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework Path Traversal vulnerability

(GHSA-g5vr-rgqm-vf78)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework MVC Applications Path Traversal Vulnerability

(GHSA-r936-gwx5-v52f)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring MVC controller vulnerable to a DoS attack

(GHSA-w3c8-7r8f-9jp8)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Build tackle2-addon-analyzer
  • GitHub Check: Unit Tests (Phase 1)
🔇 Additional comments (44)
java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/b0/6044a0b788b00010150f900a41fc8a5f (1)

1-5: Verify intent of checking in Eclipse workspace metadata and .history directory.

This file is located in Eclipse's .history directory, which contains auto-generated workspace snapshots typically excluded from version control. Additionally, the path contains a nested .metadata/.metadata/ structure, which is unusual.

If the intent is to ensure reproducible test fixtures with specific Eclipse settings (Java 17 target, forbidden reference warnings, etc.), this approach works but requires explicit documentation. Otherwise, .metadata/ and .history/ directories are generally better left out of VCS.

Questions:

  1. Is the nested .metadata/.metadata/ intentional, or does the path need adjustment?
  2. Is there a documented reason for including Eclipse .history snapshots in the test project? If so, consider adding a note in the integration test README.
java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.core/javaLikeNames.txt (1)

1-1: Metadata file for test infrastructure — LGTM.

This metadata file is appropriate for the Eclipse JDT test scaffolding. However, note the unusual double .metadata/ in the path; verify this is intentional and not an artifact of project export/setup.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt (1)

1-19: Metadata file for test infrastructure — LGTM.

This Eclipse JDT saved index file is a valid part of the test project metadata. The INDEX VERSION header and 18 index entries follow the expected format. However, verify the double .metadata/ path structure is intentional and not an artifact of tooling setup (same concern as the sibling javaLikeNames.txt file).

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/1a/b04dc5b688b00010150f900a41fc8a5f (1)

1-3: Verify that Eclipse metadata should be committed to the repository.

This file is Eclipse IDE workspace metadata/preferences located in a .metadata/.history directory. While it makes sense to commit test project configurations for reproducibility, Eclipse's .metadata directories are typically auto-generated and transient.

Consider: Should this be part of the repository, or should the test infrastructure regenerate these preferences during setup? If metadata is to be committed, document the rationale in the test README.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.jdt.launching/.install.xml (1)

1-6: Verify environment portability and version control approach for Eclipse metadata file.

This file hardcodes system-specific JDK paths and is checked into version control, which raises portability concerns:

  1. The paths are architecture-specific (aarch64 only) and won't work on x86_64 systems.
  2. The paths depend on exact JDK installations at specific locations—if the test environment doesn't have these exact paths, the file becomes stale.
  3. This is Eclipse workspace metadata (.metadata/.plugins/) which is typically excluded from version control and auto-generated per environment.

Please clarify the testing approach:

  • Does the Dockerfile/container definition ensure these exact JDK paths exist?
  • Should this file be auto-generated during test environment setup, or is it intentionally pinned?
  • How will this work across different architectures (x86_64, aarch64) or for developers with different JDK installations?

If this is meant to be container-specific, consider documenting this dependency in a README or Dockerfile comment. If it should work across environments, consider generating it dynamically rather than checking it into version control.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/b1/a0f1b8b688b00010150f900a41fc8a5f (1)

1-2: ****

The review comment targets a file that does not exist in the repository. No .metadata/ directories or files are present in the codebase, meaning there is nothing to remove from version control. The review comment appears to be based on incorrect context and should be dismissed.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1)

3-5: No action required.

The review comment incorrectly flagged missing Spring Data dependencies. The pom.xml properly declares spring-data-jpa and imports spring-data-bom in the dependency management section. The imports of Page and Pageable will resolve correctly.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/be/3086c6b688b00010150f900a41fc8a5f (1)

1-4: This review comment is incorrect and should be disregarded.

The file referenced in the review comment does not exist in the repository. The path java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/be/3086c6b688b00010150f900a41fc8a5f was not found despite exhaustive searches.

Verification confirmed:

  • No .metadata/ directories are present in the repository
  • No .history/ directories exist
  • The java-analyzer-bundle.test/ directory contains only normal Eclipse project files (.classpath, .project, .settings/ with standard configuration)
  • No instances of the referenced file hash exist

The repository is in the correct state with IDE metadata properly excluded. No action is required.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1)

1-27: LGTM! Clean enum structure.

The enum constants, fields, constructor, and accessors are well-structured and follow standard Java conventions.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (1)

1-16: LGTM! Well-defined annotation.

The annotation structure is correct with appropriate retention policy and targets for marking deprecated APIs in tests.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1)

1-43: LGTM! Test fixture methods are well-implemented.

All methods in the Calculator class are correctly implemented for integration testing purposes:

  • The divide method properly guards against division by zero
  • The deprecated sum method appropriately uses the @DeprecatedApi annotation
  • The getStatus method correctly references the EnumExample enum
java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.launching.prefs (1)

1-2: Review comment references a file that does not exist in the repository.

The file java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.launching.prefs is not present in the codebase. No .metadata/.metadata/ directories or org.eclipse.jdt.launching.prefs files exist anywhere in this repository.

All concerns raised in the original review comment are therefore invalid and should be disregarded.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (2)

8-14: LGTM! Clear test purpose documented.

The Javadoc clearly documents that this servlet is for testing package imports and Jakarta EE API references, which aligns with the PR's Phase 2 integration testing objectives.


16-21: LGTM! Simple and appropriate for testing.

The doGet implementation is straightforward and suitable for integration testing purposes.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/cd/d055a1b788b00010150f900a41fc8a5f (1)

1-7: The review comment is incorrect. The PR is removing Eclipse metadata files, not adding them.

The git status shows these files are marked with "D" (deleted), not "A" (added). The file referenced in the review comment (java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/cd/d055a1b788b00010150f900a41fc8a5f) is being deleted from the repository.

The PR fulfills the exact recommendation made in the review comment—removing the entire .metadata directory and its contents. No action is needed.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1)

13-29: LGTM!

The Spring WebApplicationInitializer setup is correctly implemented with proper context configuration, package scanning, and servlet registration.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql (1)

1-5: LGTM!

The test data inserts are well-structured and appropriate for integration testing.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1)

7-11: LGTM!

The configuration correctly excludes DataSourceAutoConfiguration, which is appropriate given the manual datasource configuration in persistence.properties.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1)

6-8: LGTM!

Standard Spring Data repository interface correctly defined with appropriate generic types.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)

19-26: LGTM!

Well-implemented custom runtime exception with proper serialVersionUID and clear constructor.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)

11-22: LGTM!

The global exception handler is properly configured to map ResourceNotFoundException to HTTP 404 responses with appropriate logging.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1)

35-38: LGTM!

The findAll method correctly uses Spring Data's Pageable support to return paginated customer results.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (3)

29-32: LGTM! Improved test name.

The renamed test method is clearer and more descriptive than the previous name.


171-174: LGTM! Proper negative test.

This test correctly verifies that unsupported commands throw UnsupportedOperationException, providing good coverage for error handling.


93-105: No action required—original review comment is incorrect.

The test does not require Java EE dependencies. The "javax.ejb.Stateless" value is a string query parameter passed to the command handler's analyzer, not an actual class dependency. All similar tests in this file use the same pattern: string queries like "java.io.*", "java.util.ArrayList", "toString", and "TestClass" are passed as symbolic patterns to search for within code. The test verifies the handler returns results; it does not require these classes or annotations to be present on the classpath.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1)

1-17: This is an Eclipse PDE test plugin; src/main/java test placement is intentional and correct.

The module uses <packaging>eclipse-test-plugin</packaging>, making it an Eclipse Plugin Development Environment test bundle. In PDE projects, test code in src/main/java is the correct convention—tests are discovered and run by Eclipse's test runner, not Maven Surefire. No changes needed.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1)

1-2: Configuration looks reasonable.

Disabling annotation processing is appropriate for projects that don't use annotation processors. This setting is clear and explicit.

java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/48/c04c9cb788b00010150f900a41fc8a5f (1)

1-2: Eclipse metadata files are correctly being removed from version control.

Verification confirms these files are staged for deletion in the PR. The git status shows all nested .metadata/.metadata/ files—including history entries, indexes, preferences, and configuration—are marked as deleted. These are auto-generated, workspace-specific, and machine-dependent artifacts that should never be tracked.

Additionally, consider adding .metadata/ to .gitignore to prevent accidental re-commits, as the current .gitignore covers other Eclipse files (.project, .classpath, .settings/) but not the .metadata/ directory itself.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1)

1-35: LGTM! Comprehensive .gitignore for test project.

The .gitignore file appropriately covers common IDE configurations, OS-specific files, editor artifacts, and Maven build outputs. The patterns are well-organized and suitable for a Java Maven test project.

java-analyzer-bundle.test/projects/test-project/pom.xml (1)

1-30: LGTM! Clean test project configuration.

The POM file is well-structured with:

  • Clear project metadata and description
  • Modern Java 17 target aligned with current standards
  • Appropriate jakarta.servlet-api dependency with correct provided scope for servlet container environments
  • Minimal dependencies suitable for a test fixture
java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/6e/c0bd9eb788b00010150f900a41fc8a5f (1)

1-2: The file referenced in this review does not exist in the repository.

The path java-analyzer-bundle.test/projects/.metadata/.metadata/.plugins/org.eclipse.core.resources/.history/6e/c0bd9eb788b00010150f900a41fc8a5f is not present anywhere in the codebase. There are no .history files, no nested .metadata/.metadata/ directories, and no .plugins directories in the test projects.

The repository only contains standard Eclipse configuration files under .settings/ (e.g., org.eclipse.jdt.core.prefs, org.eclipse.core.resources.prefs), which are appropriate and necessary for integration tests that load Java projects into a JDT.LS workspace, as documented in java-analyzer-bundle.test/projects/README.md and java-analyzer-bundle.test/integration/README.md.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/README.md (1)

1-288: Excellent documentation for the test projects!

This README provides comprehensive coverage of the test infrastructure, including:

  • Clear project overviews with technology stacks
  • Detailed location type coverage (0-14)
  • Practical test scenario examples
  • Integration test strategy with phased approach
  • Guidance for adding new test projects

The coverage matrix and migration pattern documentation will be particularly valuable for maintainers and contributors.

pom.xml (2)

26-26: Correct alignment of coverage filter with project packages.

The coverage filter change from org.eclipse.jdt.ls.* to io.konveyor.tackle.* properly aligns with the actual project package structure, ensuring code coverage reports accurately reflect the codebase.


148-166: Well-configured Jacoco coverage reporting.

The addition of prepare-agent and report executions follows Jacoco best practices:

  • prepare-agent instruments code before tests run
  • append=true enables merging coverage from multiple test executions
  • report goal in the verify phase generates coverage reports

These changes support the CI/CD integration testing infrastructure introduced in this PR.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1)

1-17: Well-designed test annotation for integration testing.

The annotation is properly configured with:

  • RUNTIME retention for reflection-based testing
  • Broad target support (TYPE, METHOD, FIELD) to cover multiple test scenarios
  • Sensible default values for flexible usage

This aligns well with the integration test strategy for location type 4 (annotation searches).

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)

1-39: Well-structured base class for integration testing.

The design effectively supports testing of multiple location types:

  • Location type 1 (inheritance): Subclasses extend BaseService
  • Location type 5 (implements type): Implements Serializable and Comparable
  • Proper serialVersionUID for Serializable implementation
  • Abstract initialize() method enforces subclass contract
  • Protected serviceName field enables subclass customization

The implementation is clean and serves its testing purpose well.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1)

1-232: Excellent comprehensive unit test coverage!

This test class provides thorough coverage of AnnotationQuery functionality with 18 test methods covering:

  • Basic constructor and getter behavior
  • Pattern matching (exact, regex, wildcard)
  • Special annotation location handling (location type 4)
  • Factory method (fromMap) with various inputs
  • Edge cases (null inputs, empty patterns, empty elements)
  • Location-specific behavior across all location types (0-14)

The tests are well-structured, properly named, and test both positive and negative scenarios. This aligns perfectly with the Phase 1 unit testing objectives mentioned in the PR.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1)

94-96: LGTM! Proper override of abstract method.

The initialize() method correctly implements the abstract method from BaseService, providing the required implementation for this concrete class.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1)

1-33: Well-designed service class for integration testing.

The class effectively demonstrates:

  • Location type 1 (inheritance): Extends BaseService
  • Location type 5 (implements type): Implements AutoCloseable
  • Location type 4 (annotation): Annotated with @CustomAnnotation
  • Proper lifecycle management with initialize() and close() methods
  • Clean state management with the initialized flag

The implementation follows the AutoCloseable pattern correctly and provides good test coverage for multiple location types.

java-analyzer-bundle.test/integration/test_helpers.go (1)

9-33: LGTM!

The helper functions are clear and correctly implement symbol verification logic for the integration tests. The early-return pattern and optional parameter handling in verifySymbolInResults is well-designed.

Dockerfile (2)

24-25: Good refactoring of build stage.

Using ENV instead of inline shell export is the correct approach for Dockerfiles, and the simplified Maven command is cleaner.


45-45: Plugin path update aligns with new architecture.

The move from /jdtls/java-analyzer-bundle/core/.../ to /jdtls/plugins/ correctly reflects the updated plugin structure referenced throughout this PR.

java-analyzer-bundle.test/projects/test-project/.classpath (1)

1-57: Classpath looks correct for Maven + Java 17

JRE container and Maven classpath entries align with the test project setup.

java-analyzer-bundle.test/integration/integration_test.go (1)

9-10: Import path is correct and properly aligned

The import "github.com/konveyor/java-analyzer-bundle/integration/client" correctly matches the module path structure in go.mod (github.com/konveyor/java-analyzer-bundle/integration). This will properly resolve to the local client package. No action required.

@shawn-hurley shawn-hurley force-pushed the testing/adding-bundle-specific-tests branch from 3f70d1f to 50e7c43 Compare October 29, 2025 17:59
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 18

♻️ Duplicate comments (8)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1)

25-26: Fix the path mapping to include path variable template.

The @GetMapping value is missing the template variable syntax. Currently, it maps to the literal path /customers/id instead of /customers/{id}, which prevents the @PathVariable("id") from binding correctly.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2)

34-46: Align project name with test suite convention.

This test uses "project" while all other tests use "test-project". This inconsistency has been flagged in previous reviews.


236-249: Replace TestClass with an existing test class.

The query for "TestClass" references a class that doesn't exist in test-project. This issue has been flagged in previous reviews—available classes include SampleApplication, Calculator, EnumExample, etc.

.github/workflows/integration-tests.yml (1)

63-71: Quote $(pwd) to prevent word splitting.

This issue has been previously identified. The unquoted $(pwd) in the volume mount will cause issues with paths containing spaces.

Apply this diff:

           podman run --rm \
-            -v $(pwd)/java-analyzer-bundle.test:/tests:Z \
+            -v "$(pwd)/java-analyzer-bundle.test:/tests:Z" \
             -e WORKSPACE_DIR=/tests/projects \
             -e JDTLS_PATH=/jdtls \
             --workdir /tests/integration \
             --entrypoint /bin/sh \
             jdtls-analyzer:test \
             -c "microdnf install -y golang && cd /tests/integration && go mod download && go test -v"
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (3)

19-19: Spring Framework version has known critical vulnerabilities.

This comment duplicates prior feedback. Spring 5.3.7 has multiple critical vulnerabilities including DoS, path traversal, and RCE.


117-119: Logback version has known critical vulnerabilities.

This comment duplicates prior feedback. Version 1.1.7 has multiple critical deserialization vulnerabilities.


127-129: PostgreSQL driver version has known critical vulnerabilities.

This comment duplicates prior feedback. Version 42.2.23 has multiple critical vulnerabilities including SQL injection, arbitrary file write, and path traversal.

java-analyzer-bundle.test/integration/client/jdtls_client.go (1)

102-116: Point -data at the workspace root.

JDT.LS expects -data to be the workspace directory and will create .metadata underneath. Passing <workspace>/.metadata causes the server to create <workspace>/.metadata/.metadata and can break workspace state. Ensure the workspace root exists and pass it directly.

@@
-	// Prepare workspace
-	dataDir := filepath.Join(c.workspaceDir, ".metadata")
-	if err := os.MkdirAll(dataDir, 0755); err != nil {
-		return fmt.Errorf("failed to create data directory: %w", err)
-	}
+	// Ensure workspace directory exists; JDT.LS will create .metadata under it
+	if err := os.MkdirAll(c.workspaceDir, 0755); err != nil {
+		return fmt.Errorf("failed to create workspace directory: %w", err)
+	}
@@
-	c.cmd = exec.Command(jdtlsBin,
-		"-configuration", configDir,
-		"-data", dataDir,
-	)
+	c.cmd = exec.Command(jdtlsBin,
+		"-configuration", configDir,
+		"-data", c.workspaceDir,
+	)
🧹 Nitpick comments (26)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1)

7-12: Consider Java interface conventions.

Two optional style improvements:

  1. The public modifier on interface methods (lines 8, 10) is redundant since interface methods are implicitly public.
  2. The "I" prefix for interface names is more of a C# convention; idiomatic Java typically omits it (e.g., CustomerService for the interface, CustomerServiceImpl for the implementation).

Apply this diff to remove redundant modifiers:

 public interface ICustomerService {
-    public Customer findById(Long id); 
+    Customer findById(Long id);
 	
-	public Page<Customer>findAll(Pageable pageable);
+	Page<Customer> findAll(Pageable pageable);
     
 }
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1)

23-97: LGTM! Standard JPA entity structure for test fixture.

The field declarations, accessor methods, and toString implementation follow standard JPA entity patterns. Column length constraints are appropriate for customer data.

Optional: Consider adding equals() and hashCode() methods based on the business key (e.g., username) for better entity semantics, though this is not critical for test fixtures.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java (2)

16-18: Consider adding @GeneratedValue for ID auto-generation.

The @Id field typically includes @GeneratedValue to enable automatic ID generation by the persistence provider. If IDs will be manually assigned in tests, the current implementation is acceptable.

Apply this diff if auto-generation is desired:

     @Id
+    @GeneratedValue
     @Column(name = "id")
     private Long id;

14-59: Well-structured test entity.

The class is clean and properly annotated for its purpose as a test fixture for JPA annotation matching. The implementation is straightforward and appropriate for integration testing.

Optionally, consider adding equals() and hashCode() methods based on the ID or business key (e.g., sku) for more robust entity behavior in collections and comparisons:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof Product)) return false;
    Product product = (Product) o;
    return Objects.equals(sku, product.sku);
}

@Override
public int hashCode() {
    return Objects.hash(sku);
}
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (1)

23-28: Set content type for consistency and proper HTTP response handling.

The doPost method should set the response content type, similar to doGet (line 19). Without it, the client may not correctly interpret the response format.

Apply this diff to set the content type:

 @Override
 protected void doPost(HttpServletRequest request, HttpServletResponse response)
         throws IOException {
+    response.setContentType("text/html");
     String data = request.getParameter("data");
     response.getWriter().println("Received: " + data);
 }

Note: The XSS vulnerability previously flagged in the past review comments at lines 26-27 should also be addressed before merging.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (2)

20-23: Consider constructor injection and making the logger final.

Field injection works but constructor injection is generally preferred for better testability and immutability. Additionally, the static logger field should be declared final.

Apply this diff to use constructor injection and make the logger final:

-	@Autowired
-	private CustomerService customerService;
+	private final CustomerService customerService;
 	
-	private static Logger logger = Logger.getLogger( CustomerController.class.getName() );
+	private static final Logger logger = Logger.getLogger( CustomerController.class.getName() );
+	
+	@Autowired
+	public CustomerController(CustomerService customerService) {
+		this.customerService = customerService;
+	}

35-38: Prefer @GetMapping over @RequestMapping for clarity.

While @RequestMapping defaults to GET when no method is specified, using @GetMapping makes the HTTP method explicit and improves code readability.

Apply this diff to use the more specific annotation:

-	@RequestMapping
+	@GetMapping
 	public Page<Customer> findAll(Pageable pageable){
 		return customerService.findAll(pageable);
 	}
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (3)

6-6: Remove unused import.

The fail import is not used anywhere in the test class.

Apply this diff:

 import static org.junit.Assert.assertNotNull;
 import static org.junit.Assert.assertTrue;
-import static org.junit.Assert.fail;

48-61: Consider consolidating duplicate tests.

testRuleEntryWithFullMode and testRuleEntryWithWildcardQuery are nearly identical—both query "java.io.*" with location "10", differing only in analysisMode. Consider using a parameterized test or extracting a helper method to reduce duplication.

Example approach using a helper method:

private void testRuleEntryWithQuery(String analysisMode, String testName) throws Exception {
    List<Object> params = new ArrayList<>();
    Map<String, String> param = Map.of(
        "project", "test-project",
        "query", "java.io.*",
        "location", "10",
        "analysisMode", analysisMode
    );
    params.add(param);
    
    List<Object> result = (List<Object>) commandHandler.executeCommand(
        SampleDelegateCommandHandler.RULE_ENTRY_COMMAND_ID, params, null);
    assertNotNull(testName + " should return non-null result", result);
}

@Test
public void testRuleEntryWithFullMode() throws Exception {
    testRuleEntryWithQuery("full", "testRuleEntryWithFullMode");
}

@Test
public void testRuleEntryWithWildcardQuery() throws Exception {
    testRuleEntryWithQuery("source-only", "testRuleEntryWithWildcardQuery");
}

Also applies to: 176-189


48-234: Consider strengthening test assertions.

Most integration tests only verify assertNotNull(result) without checking result content. While this confirms execution completes, consider adding assertions to verify:

  • Expected result size (e.g., assertTrue(!result.isEmpty()) when matches are expected)
  • Presence of specific symbols/locations
  • Result structure correctness

This would increase confidence that the search functionality returns correct results, not just non-null values.

Example for testRuleEntryWithMethodCallLocation:

 List<Object> result = (List<Object>) commandHandler.executeCommand(SampleDelegateCommandHandler.RULE_ENTRY_COMMAND_ID, params, null);
 assertNotNull(result);
+assertTrue("Should find println method calls", !result.isEmpty());
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (2)

4-4: Consider using SLF4J for better Spring integration.

JBoss Logging is uncommon in Spring projects. SLF4J is the de facto logging facade for Spring applications and provides better interoperability with various logging implementations.

If you'd like to standardize on SLF4J, apply this diff:

-import org.jboss.logging.Logger;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;

And update line 14:

-	private static Logger logger = Logger.getLogger( ExceptionHandlingController.class.getName() );
+	private static final Logger logger = LoggerFactory.getLogger(ExceptionHandlingController.class);

14-14: Add final modifier to the static logger field.

Static fields that are not intended to be reassigned should be marked as final to prevent accidental modification and clearly communicate immutability.

Apply this diff:

-	private static Logger logger = Logger.getLogger( ExceptionHandlingController.class.getName() );
+	private static final Logger logger = Logger.getLogger(ExceptionHandlingController.class.getName());
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)

9-39: Consider overriding equals() and hashCode() for consistency with Comparable.

When a class implements Comparable, it's recommended to also override equals() and hashCode() to ensure consistency: if compareTo() returns 0, equals() should return true.

Example implementation:

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (obj == null || getClass() != obj.getClass()) return false;
    BaseService that = (BaseService) obj;
    return Objects.equals(serviceName, that.serviceName);
}

@Override
public int hashCode() {
    return Objects.hash(serviceName);
}
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1)

25-28: Consider using a more specific exception type.

The close() method declares throws Exception, which is overly broad. For better clarity and type safety, consider declaring a more specific exception type (or no exception if none are actually thrown).

If no exceptions are thrown, you can simplify to:

 @Override
-public void close() throws Exception {
+public void close() {
     this.initialized = false;
     System.out.println("DataService closed");
 }
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (2)

156-173: Consider parameterized tests for better failure diagnostics.

The loop-based approach efficiently tests all 15 location types, but when a failure occurs, it's harder to identify which specific location value failed. Consider using JUnit's @Parameterized runner or separate test methods for each location to improve failure diagnostics and make the test results more granular.

Example using JUnit 4 Parameterized:

@RunWith(Parameterized.class)
public class RuleEntryParamsLocationTest {
    
    @Parameterized.Parameters(name = "location={0}")
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][] {
            {0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, 
            {8}, {9}, {10}, {11}, {12}, {13}, {14}
        });
    }
    
    @Parameterized.Parameter
    public int location;
    
    @Test
    public void testLocation() {
        List<Object> arguments = new ArrayList<>();
        Map<String, Object> params = new HashMap<>();
        params.put("project", "test-project");
        params.put("query", "test.query");
        params.put("location", String.valueOf(location));
        params.put("analysisMode", "full");
        arguments.add(params);

        RuleEntryParams ruleParams = new RuleEntryParams("test-command", arguments);
        assertEquals(location, ruleParams.getLocation());
    }
}

19-217: Strong positive and negative test coverage.

The test methods effectively cover normal operation scenarios, optional parameters, boolean flags, collections, and nested objects. The separation of concerns (one aspect per test) makes the suite maintainable and easy to understand.

For even more robust validation, consider adding edge case tests:

  • Empty strings for required parameters (project, query, analysisMode)
  • Negative or out-of-range location values (e.g., -1, 15, 100)
  • Empty collections for includedPaths
  • Malformed annotationQuery structures
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java (3)

8-16: Docs/code mismatch; clarify intent (variable binding vs. presence).

Comment says “variable binding,” but no setXXX(...) calls are present. Confirm intent:

  • If goal is only “PreparedStatement without EntityManager,” update comment.
  • If goal is “variable binding,” add a bound parameter (see next comment’s diff).

19-30: Use try‑with‑resources to avoid leaks; optionally demonstrate binding.

Manual closes can leak on exceptions. Prefer try-with-resources. If you want to actually show binding, use a placeholder and setString(...).

Apply:

-    public void executeQuery(Connection conn) throws SQLException {
-        // Uses only JDBC PreparedStatement
-        PreparedStatement stmt = conn.prepareStatement("SELECT * FROM products");
-        ResultSet rs = stmt.executeQuery();
-
-        while (rs.next()) {
-            System.out.println("Product: " + rs.getString("name"));
-        }
-
-        rs.close();
-        stmt.close();
-    }
+    public void executeQuery(Connection conn) throws SQLException {
+        // Uses only JDBC PreparedStatement (no EntityManager)
+        try (PreparedStatement stmt =
+                     conn.prepareStatement("SELECT name FROM products WHERE name LIKE ?")) {
+            // Optional binding to exercise parameterized queries in tests
+            stmt.setString(1, "%");
+            try (ResultSet rs = stmt.executeQuery()) {
+                while (rs.next()) {
+                    System.out.println("Product: " + rs.getString("name"));
+                }
+            }
+        }
+    }

24-26: Avoid System.out in test assets that may run under CI.

Consider returning a list of names or using a logger to keep CI output clean.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (2)

14-15: Document elements and (optionally) add forRemoval for parity with JDK @deprecated.

  • Brief Javadoc on since/replacement clarifies intent in tests.
  • Optional: add boolean forRemoval defaulting to false; backward compatible and useful for assertions.
 public @interface DeprecatedApi {
-    String since() default "";
-    String replacement() default "";
+    /**
+     * Version the API became deprecated (e.g., "1.0").
+     */
+    String since() default "";
+    /**
+     * Suggested replacement API signature or identifier.
+     */
+    String replacement() default "";
+    /**
+     * Indicates the API is intended to be removed in a future release.
+     */
+    boolean forRemoval() default false;
 }

3-13: Add @documented and expand @target for better test coverage.

The test project is configured for Java 17, which fully supports all proposed annotation targets (TYPE_PARAMETER, TYPE_USE added in Java 8). Mark the annotation @documented so it appears in generated Javadoc, and expand @target to exercise more code locations in integration tests.

Apply:

 import java.lang.annotation.ElementType;
+import java.lang.annotation.Documented;
 import java.lang.annotation.Retention;
 import java.lang.annotation.RetentionPolicy;
 import java.lang.annotation.Target;

 /**
  * Annotation for marking deprecated APIs.
  */
+@Documented
 @Retention(RetentionPolicy.RUNTIME)
-@Target({ElementType.TYPE, ElementType.METHOD})
+@Target({
+    ElementType.TYPE,
+    ElementType.METHOD,
+    ElementType.FIELD,
+    ElementType.PARAMETER,
+    ElementType.CONSTRUCTOR,
+    ElementType.TYPE_PARAMETER,
+    ElementType.TYPE_USE
+})
 public @interface DeprecatedApi {
java-analyzer-bundle.test/README.md (1)

1-296: Excellent comprehensive documentation!

This README provides thorough coverage of the test infrastructure, including:

  • Clear quick start guide
  • Well-organized structure with Phase 1 and Phase 2 sections
  • Complete coverage matrix for all 15 location types
  • Migration testing examples
  • CI/CD pipeline documentation

Optional: Add language identifier to fenced code block

The static analysis tool flagged line 213 for missing a language specification on a fenced code block. Consider adding a language identifier (e.g., bash, java, or text) to improve rendering and syntax highlighting.

java-analyzer-bundle.test/docs/integration-tests.md (1)

1-800: Excellent integration test documentation!

This comprehensive guide covers:

  • Clear architecture diagrams
  • Detailed component descriptions
  • Multiple execution methods (local, container, CI)
  • Test scenarios for all location types
  • Migration testing patterns
  • Troubleshooting guidance

Optional: Minor grammar refinement

Consider hyphenating "5-second wait" on line 384 for improved readability, though this is a very minor nitpick.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1)

19-52: Remove unused query field or implement filtering logic.

The query field is confirmed as unused in EnumConstantSymbolProvider.get(). However, peer implementations (MethodCallSymbolProvider, AnnotationSymbolProvider, ConstructorCallSymbolProvider, TypeSymbolProvider, ReturnTypeSymbolProvider) actively use query for filtering. Either:

  • Remove the unused field if enum constant filtering is not needed, or
  • Implement query-based filtering logic consistent with other providers (e.g., check if (this.query.contains(".")) before adding symbols).
java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (2)

9-9: Add .PHONY declaration for 'all' target.

The all target should be declared .PHONY for consistency with other targets and to follow Makefile best practices.

Apply this diff:

+.PHONY: all
 all: build

20-36: Consider using container runtime detection for consistency.

The root Makefile (line 6-10) detects Podman/Docker dynamically, but this Makefile hardcodes docker. For consistency and flexibility, consider using the same runtime detection pattern.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3f70d1f and 50e7c43.

⛔ Files ignored due to path filters (1)
  • java-analyzer-bundle.test/integration/go.sum is excluded by !**/*.sum
📒 Files selected for processing (73)
  • .github/workflows/integration-tests.yml (1 hunks)
  • .gitignore (1 hunks)
  • Dockerfile (2 hunks)
  • Dockerfile.test (1 hunks)
  • Makefile (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (6 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java (4 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/AnnotationSymbolProvider.java (4 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (3 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (9 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/MethodCallSymbolProvider.java (3 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (2 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/WithSearchPattern.java (1 hunks)
  • java-analyzer-bundle.test/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/integration-tests.md (1 hunks)
  • java-analyzer-bundle.test/docs/query-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/quick-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/test-projects.md (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
  • java-analyzer-bundle.test/integration/go.mod (1 hunks)
  • java-analyzer-bundle.test/integration/integration_test.go (1 hunks)
  • java-analyzer-bundle.test/integration/run_local.sh (1 hunks)
  • java-analyzer-bundle.test/integration/test_helpers.go (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.classpath (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.project (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/ServiceWithEntityManager.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1 hunks)
  • pom.xml (3 hunks)
✅ Files skipped from review due to trivial changes (1)
  • java-analyzer-bundle.test/docs/test-projects.md
🚧 Files skipped from review as they are similar to previous changes (17)
  • java-analyzer-bundle.test/integration/go.mod
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java
  • java-analyzer-bundle.test/integration/test_helpers.go
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java
  • pom.xml
🧰 Additional context used
🧬 Code graph analysis (11)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java (2)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1)
  • EnumConstantSymbolProvider (19-53)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1)
  • PackageDeclarationSymbolProvider (16-84)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1)
  • DataSourceDefinition (9-21)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1)
  • MessageDriven (12-23)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/MethodCallSymbolProvider.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1)
  • CustomASTVisitor (28-279)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1)
  • DataSourceDefinition (9-21)
java-analyzer-bundle.test/integration/integration_test.go (1)
java-analyzer-bundle.test/integration/client/jdtls_client.go (4)
  • JDTLSClient (19-28)
  • NewJDTLSClient (87-96)
  • AnnotationQuery (252-255)
  • AnnotationElement (246-249)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1)
  • MessageDriven (12-22)
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (1)
  • SampleDelegateCommandHandler (43-427)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1)
  • CustomASTVisitor (28-279)
🪛 actionlint (1.7.8)
.github/workflows/integration-tests.yml

63-63: shellcheck reported issue in this script: SC2046:warning:2:6: Quote this to prevent word splitting

(shellcheck)

🪛 checkmake (0.2.2)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile

[warning] 38-38: Missing required phony target "all"

(minphony)


[warning] 38-38: Missing required phony target "test"

(minphony)


[warning] 9-9: Target "all" should be declared PHONY.

(phonydeclared)

Makefile

[warning] 25-25: Target body for "help" exceeds allowed length of 5 (24).

(maxbodylength)


[warning] 115-115: Target body for "clean" exceeds allowed length of 5 (6).

(maxbodylength)

🪛 LanguageTool
java-analyzer-bundle.test/docs/integration-tests.md

[grammar] ~384-~384: Use a hyphen to join words.
Context: ...: JDT.LS needs time to index projects (5 second wait in Initialize()) 2. **Build ...

(QB_NEW_EN_HYPHEN)

java-analyzer-bundle.test/docs/query-reference.md

[grammar] ~608-~608: Ensure spelling is correct
Context: ...**: ~5 seconds Per-Query Time: ~100-500ms depending on result count **Result Coun...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

java-analyzer-bundle.test/docs/README.md

[style] ~73-~73: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...uick-reference.md#running-tests) ### I want to understand what's tested → [Quick Refer...

(REP_WANT_TO_VB)


[style] ~77-~77: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...erence.md#tested-search-queries) ### I want to add a new test → [Integration Tests Gui...

(REP_WANT_TO_VB)


[style] ~81-~81: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...ence.md#untested-query-patterns) ### I want to understand the architecture → [Integrat...

(REP_WANT_TO_VB)


[style] ~85-~85: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...integration-tests.md#components) ### I want to understand test projects → [Test Projec...

(REP_WANT_TO_VB)


[style] ~89-~89: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...est-projects.md#coverage-matrix) ### I want to add Java test code → [Test Projects - A...

(REP_WANT_TO_VB)


[style] ~95-~95: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...ration-tests.md#troubleshooting) ### I want to understand migration testing → [Query R...

(REP_WANT_TO_VB)

🪛 markdownlint-cli2 (0.18.1)
java-analyzer-bundle.test/README.md

213-213: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/quick-reference.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


62-62: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/integration-tests.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


311-311: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/README.md

213-213: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🪛 OSV Scanner (2.2.3)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml

[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: QOS.ch Logback vulnerable to Deserialization of Untrusted Data

(GHSA-vmfg-rjjm-rjrj)


[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: logback serialization vulnerability

(GHSA-vmq6-5m68-f53m)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: org.postgresql:postgresql vulnerable to SQL Injection via line comment generation

(GHSA-24rp-q3w6-vc56)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: TemporaryFolder on unix-like systems does not limit access to created files

(GHSA-562r-vg33-8x8h)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Arbitrary File Write Vulnerability

(GHSA-673j-qm5f-xpv8)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: Path traversal in org.postgresql:postgresql

(GHSA-727h-hrw8-jg8q)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names

(GHSA-r38f-c4h4-hqq2)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Does Not Check Class Instantiation when providing Plugin Classes

(GHSA-v7wg-cpwc-24m4)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DoS via conditional HTTP request

(GHSA-2rmj-mq67-h97g)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation

(GHSA-2wrp-6fg6-hmc5)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DataBinder Case Sensitive Match Exception

(GHSA-4gc7-5j7h-4qph)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Pivotal Spring Framework contains unsafe Java deserialization methods

(GHSA-4wrc-f8pq-fpqp)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Web vulnerable to Open Redirect or Server Side Request Forgery

(GHSA-ccgv-vj62-xf9h)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation Vulnerability

(GHSA-hgjh-9rj2-g67j)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Remote Code Execution in Spring Framework

(GHSA-36p3-wjmg-h94x)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework is vulnerable to security bypass via mvcRequestMatcher pattern mismatch

(GHSA-7phw-cxx7-q9vq)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Path traversal vulnerability in functional web frameworks

(GHSA-cx7f-g6mp-7hqm)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework Path Traversal vulnerability

(GHSA-g5vr-rgqm-vf78)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework MVC Applications Path Traversal Vulnerability

(GHSA-r936-gwx5-v52f)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring MVC controller vulnerable to a DoS attack

(GHSA-w3c8-7r8f-9jp8)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Build tackle2-addon-analyzer
🔇 Additional comments (52)
.gitignore (1)

7-7: Good addition to support test infrastructure.

The pattern */projects/.metadata appropriately ignores IDE metadata directories within test project hierarchies, preventing unnecessary VCS noise as test projects are scaffolded during the integration testing phase.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (3)

1-11: LGTM!

The imports and documentation are appropriate for a JMS message-driven bean test fixture. The Javadoc clearly explains the test's purpose.


12-17: LGTM!

The @MessageDriven configuration is valid and properly structured. The activation config properties correctly specify a queue-based JMS destination, complementing the topic-based TopicMessageProcessor in the test suite.


19-22: LGTM!

The onMessage implementation is appropriately simple for a test fixture. The goal is to exercise the analyzer's detection capabilities, not to perform actual message processing.

java-analyzer-bundle.test/projects/test-project/.project (1)

1-34: LGTM! Standard Eclipse project configuration.

The project descriptor is correctly configured with Java and Maven builders, appropriate natures, and sensible resource filters.

java-analyzer-bundle.test/projects/test-project/pom.xml (1)

1-62: LGTM! Well-structured Maven POM for testing.

The configuration is appropriate for a test project with Java 17, UTF-8 encoding, and provided-scope dependencies. The mix of Jakarta EE 9+ (jakarta.servlet) and older Java EE APIs (javax.*) appears intentional for comprehensive testing coverage across API generations.

java-analyzer-bundle.test/projects/test-project/.classpath (1)

1-57: LGTM! Standard Eclipse classpath for Maven projects.

The classpath correctly maps the Maven project structure with JavaSE-17 (consistent with the POM), includes annotation processing support, and properly distinguishes test from production sources.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1)

1-8: LGTM! Standard Spring Data repository for test fixture.

This is a correctly structured Spring Data repository interface. The empty interface extending PagingAndSortingRepository<Customer, Long> is standard practice, as Spring Data will generate the implementation at runtime with full CRUD and pagination support.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1)

15-19: Verify the intentional use of initialValue = 6 for test data.

The sequence generator specifies initialValue = 6, which is unusual. This suggests the test database is pre-seeded with 5 customer records. Please confirm this aligns with your test data setup expectations.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (2)

1-7: LGTM!

The package declaration and imports correctly set up the mixed JPA/JDBC scenario that this test class is designed to demonstrate.


9-17: LGTM!

The class structure and documentation clearly explain the test scenario. The EntityManager field is properly annotated with @PersistenceContext for JPA dependency injection.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (3)

1-11: LGTM! Clear documentation and appropriate imports.

The package structure, imports, and JavaDoc clearly document this servlet's purpose for testing Jakarta EE API references and package imports.


12-15: LGTM! Proper servlet class structure.

The class properly extends HttpServlet and includes the required serialVersionUID field.


16-21: LGTM! Properly implemented doGet handler.

The method correctly sets the content type and returns a simple HTML response.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (2)

23-24: LGTM! Enhanced matching with readable type conversion.

The conversion from JVM signatures to readable type names (e.g., "I" → "int") significantly improves the matching capability. Users can now search using human-readable type names, while the original JVM signature matching is preserved for backward compatibility.

Also applies to: 35-35


27-27: Good logging enhancement.

Including the readable type in log statements alongside the JVM signature provides better visibility into the matching behavior during debugging.

Also applies to: 34-34

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1)

171-174: LGTM!

The exception handling test correctly verifies that unsupported commands throw UnsupportedOperationException.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (4)

1-5: LGTM!

The imports are appropriate for JPA operations and align with the test class purpose.


7-15: LGTM!

Excellent documentation that clearly explains the test scenarios and expected analyzer behavior. This makes the test fixture's purpose very clear.


18-19: LGTM!

The EntityManager field is properly annotated with @PersistenceContext for container-managed injection.


21-27: ****

The original review comment misunderstood the purpose of this file. The javadoc comments clearly document that PureJpaService is a test class for variable binding and static analyzer testing, not production code meant to be executed:

"Test class for variable binding. This file has EntityManager but NO PreparedStatement."

The intentionally invalid code (persisting new Object() and referencing a non-existent User entity) is by design—it's a test fixture meant to verify that the static analyzer can correctly detect EntityManager usage patterns. The code is not meant to compile or execute successfully; it exists solely for analyzer testing purposes.

No fixes or clarifications are needed. The code should remain as-is.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)

11-12: LGTM!

The @ControllerAdvice annotation correctly designates this class as a global exception handler for Spring MVC controllers.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (3)

9-13: LGTM! Well-structured base class for testing.

The class declaration properly implements both Serializable and Comparable interfaces, includes the required serialVersionUID, and uses protected visibility for serviceName to enable subclass customization.


15-17: LGTM!

Constructor correctly initializes the serviceName field.


27-33: LGTM!

The lifecycle methods provide clear status messages using the serviceName field.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (4)

8-11: LGTM! Good test class structure.

The class properly extends BaseService while adding AutoCloseable capability, and includes the CustomAnnotation for testing annotation-based location searches.


13-16: LGTM!

The constructor correctly calls the parent constructor and customizes the serviceName field for this service implementation.


19-22: LGTM!

The initialize() override properly implements the abstract method contract and manages the initialized state.


30-32: LGTM!

Simple and clear accessor method for the initialization state.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1)

1-17: LGTM! Comprehensive test coverage with clear structure.

The test class is well-organized with appropriate imports and covers a wide range of scenarios including parameter parsing, analysis modes, path configurations, Maven settings, location types, annotation queries, and error conditions.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (2)

21-27: Configuration class annotations look good.

The combination of @Configuration, @EnableJpaRepositories, @EnableTransactionManagement, and @EnableSpringDataWebSupport is appropriate for a Spring JPA configuration class.


60-63: Bean implementation is correct.

The PersistenceExceptionTranslationPostProcessor bean is correctly implemented following standard Spring patterns.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (2)

1-16: Test class structure looks good for analyzer testing.

The imports, annotation, and class structure correctly implement a topic-based MDB pattern that mirrors the existing queue-based MessageProcessor. This will effectively test the analyzer's ability to detect topic-specific configurations.

One minor observation: MessageProcessor includes an acknowledgeMode property in its activation config, while this class doesn't. If intentional (to test different configuration scenarios), this is fine. If the goal is parallel coverage, you might consider adding it for consistency.


18-21: LGTM!

The onMessage implementation is appropriate for testing purposes. The log message clearly distinguishes topic processing from queue processing, which will help validate test results.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1)

7-8: ****

The original concern about @EnableAutoConfiguration placement is unfounded. This is a valid and intentional pattern for the test project:

  • Single configuration point: Only one @EnableAutoConfiguration exists in the codebase—no conflicts possible.
  • Deliberate exclusion: DataSourceAutoConfiguration is explicitly excluded because PersistenceConfig provides a custom DataSource bean with application-specific JDBC configuration.
  • Test project pattern: The "tomcat-legacy" naming indicates a servlet-based application (not Spring Boot), where selectively enabling auto-configuration while customizing specific components is a standard approach.

The code is correct and requires no changes.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (2)

1-16: LGTM — concise, correct annotation definition.
Clean, compiles as-is, and suits the test project need.


1-1: Repository does not enforce license headers; this file aligns with project convention.

The codebase shows no license header requirements. Java files across java-analyzer-bundle.core, java-analyzer-bundle.test, and the test project consistently start with package statements. Only one file in the repository (in the separate customers-tomcat-legacy project) contains a header. Build configurations lack license header enforcement plugins. DeprecatedApi.java follows the established pattern.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1)

1-2: LGTM! Standard Eclipse configuration.

This Eclipse preferences file appropriately disables annotation processing for the test project.

Dockerfile (2)

25-26: LGTM! Improved environment variable handling.

Using ENV to declare JAVA_HOME is cleaner and more maintainable than setting it inline with the RUN command.


52-52: LGTM! Correct plugin path alignment.

The updated destination path /jdtls/plugins/ correctly aligns with JDT.LS plugin directory structure and matches the integration test expectations.

java-analyzer-bundle.test/integration/run_local.sh (1)

1-57: LGTM! Well-structured local test runner.

The script demonstrates good practices:

  • Automatic container runtime detection (Podman/Docker)
  • Proper SELinux handling with :Z flag for Podman
  • Clear error handling with set -e
  • Preserves test exit codes for CI integration
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1)

1-36: LGTM! Well-structured test enum.

The enum design is appropriate for testing enum constant searches (location type 6). The fromCode() method returning null on no match is acceptable for test code, though production code would typically use Optional<EnumExample> or throw an exception.

.github/workflows/integration-tests.yml (1)

1-72: Well-structured CI/CD workflow!

The two-phase testing approach is excellent:

  • Phase 1: Maven unit tests with artifact upload
  • Phase 2: Containerized integration tests with proper dependency chain

The workflow includes good practices like timeouts, proper checkout actions, and test result preservation.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (2)

165-205: LGTM! Enhanced search pattern matching for generics and enum constants.

The additions of R_ERASURE_MATCH for locations 7, 9, 3, and 12 properly support matching parameterized types (e.g., List<String> when searching for java.util.List). The new case 6 for enum constants correctly treats them as field references. The explanatory comments are helpful.


354-354: Constructor signature correctly updated to pass SearchPattern.

The updated call to SymbolInformationTypeRequestor correctly passes the pattern parameter, aligning with the new constructor signature introduced in this PR.

Makefile (2)

6-17: LGTM! Excellent container runtime detection with proper volume flags.

The Podman-first detection with Docker fallback is a good practice. The :Z volume flag for Podman correctly handles SELinux labeling on systems where it's required.


96-112: Integration test execution is well-structured.

The test execution properly:

  • Mounts the test directory with appropriate volume flags
  • Sets required environment variables (WORKSPACE_DIR, JDTLS_PATH)
  • Installs Go and runs tests in a single container run
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java (2)

37-49: LGTM! SearchPattern integration follows established pattern.

The addition of the searchPattern field and constructor parameter aligns well with the existing WithQuery, WithAnnotationQuery, and WithMaxResults pattern. Proper initialization in the constructor.


90-92: Proper propagation of SearchPattern to symbol providers.

The conditional check and propagation logic correctly mirrors the existing pattern for other provider capabilities (WithQuery, WithAnnotationQuery, WithMaxResults).

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1)

1-21: LGTM! Well-documented test fixture for MySQL DataSource annotation testing.

This test class properly complements DataSourceConfig.java by providing a MySQL variant for testing annotation-based symbol matching with different database drivers. The documentation clearly explains its purpose.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/WithSearchPattern.java (1)

1-7: LGTM! Clean interface design following established patterns.

The WithSearchPattern interface follows the same design pattern as existing capability interfaces (WithQuery, WithAnnotationQuery, WithMaxResults), providing a consistent way to configure symbol providers.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1)

1-21: LGTM! Well-documented test fixture for PostgreSQL DataSource annotation testing.

This test class provides proper coverage for @DataSourceDefinition annotation matching. Works well alongside MySQLDataSourceConfig.java to test multiple driver variants. Clear documentation of its testing purpose.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
.github/workflows/integration-tests.yml (1)

72-72: Quote $(pwd) to prevent word-splitting and fix SC2046 shellcheck warning.

The unquoted command substitution will break when the workspace path contains spaces. This was flagged in previous review; apply the fix:

          podman run --rm \
-           -v $(pwd)/java-analyzer-bundle.test:/tests:Z \
+           -v "$(pwd)/java-analyzer-bundle.test:/tests:Z" \
             -e WORKSPACE_DIR=/tests/projects \
             -e JDTLS_PATH=/jdtls \
             --workdir /tests/integration \
             --entrypoint /bin/sh \
             jdtls-analyzer:test \
             -c "microdnf install -y golang && cd /tests/integration && go mod download && go test -v"
🧹 Nitpick comments (2)
.github/workflows/integration-tests.yml (2)

17-17: Standardize setup-java action version.

Line 17 uses actions/setup-java@v5 while line 44 uses @v4. Standardize to @v5 for consistency across the workflow.

      - name: Set up JDK 17
-       uses: actions/setup-java@v4
+       uses: actions/setup-java@v5
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: maven

Also applies to: 44-44


50-53: Go setup on runner may be redundant.

The workflow installs Go inside the container (line 78: microdnf install -y golang), making the setup-go step on lines 50–53 potentially unused. Consider removing it if the Go binary from the container is the only one needed, or document if it's kept as a fallback pattern.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1f74a09 and 4de9ff2.

📒 Files selected for processing (2)
  • .github/workflows/integration-tests.yml (1 hunks)
  • pom.xml (4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Build tackle2-addon-analyzer
  • GitHub Check: Unit Tests (Phase 1)
🔇 Additional comments (3)
pom.xml (3)

26-26: Coverage filter correctly scoped to Konveyor Tackle.

Aligns with the project's rebranding and ensures coverage reporting focuses on organization-specific code.


73-73: Headless test execution appropriate for CI/CD.

Disabling UI harness is correct for containerized and headless CI environments.


148-166: JaCoCo configuration enhancement properly structured.

The new report execution bound to the verify phase follows Maven best practices and will generate coverage reports after all tests complete. The append: true configuration correctly handles multiple test execution merging.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

♻️ Duplicate comments (1)
java-analyzer-bundle.test/integration/client/jdtls_client.go (1)

305-359: Critical: Shutdown still panics when c.conn is nil (past issue not fully addressed).

The past review identified that if Start() fails before establishing c.conn, calling Shutdown() will panic at line 314 when dereferencing a nil connection. This issue is still present in the code.

Add a nil guard at the beginning of Shutdown():

 func (c *JDTLSClient) Shutdown() error {
 	c.logger.Info("Shutting down JDT.LS server...")
 
+	// If connection was never established, just clean up the process
+	if c.conn == nil {
+		if c.cancel != nil {
+			c.cancel()
+		}
+		if c.dialer != nil {
+			_ = c.dialer.Close()
+		}
+		if c.cmd != nil && c.cmd.Process != nil {
+			if err := c.cmd.Process.Kill(); err != nil {
+				c.logger.Debugf("Process kill failed: %v", err)
+			}
+			// Don't wait indefinitely
+			done := make(chan error, 1)
+			go func() { done <- c.cmd.Wait() }()
+			select {
+			case <-done:
+			case <-time.After(2 * time.Second):
+			}
+		}
+		c.logger.Info("Cleaned up partially started server")
+		return nil
+	}
+
 	// Create a context with timeout for shutdown requests
 	shutdownCtx, shutdownCancel := context.WithTimeout(c.ctx, 3*time.Second)
🧹 Nitpick comments (4)
java-analyzer-bundle.test/integration/client/jdtls_client.go (4)

212-213: Fixed sleep is brittle for waiting on server readiness.

The 5-second sleep assumes the server will be ready within that time, which may be too short on slower systems or unnecessarily long on faster ones.

Consider polling for project readiness or using a server notification. For example, wait for specific server status or build completion events if JDT.LS provides them, or implement a retry loop that attempts a lightweight query until it succeeds.


262-268: Consider accepting location as string to match API expectations.

The location parameter is immediately converted to a string at line 266, suggesting the underlying API expects a string. Accepting it as string would simplify the signature and avoid unnecessary conversions.

-func (c *JDTLSClient) SearchSymbolsWithAnnotation(project, query string, location int, analysisMode string, includedPaths []string, annotationQuery *AnnotationQuery) ([]protocol.SymbolInformation, error) {
+func (c *JDTLSClient) SearchSymbolsWithAnnotation(project, query string, location string, analysisMode string, includedPaths []string, annotationQuery *AnnotationQuery) ([]protocol.SymbolInformation, error) {
 	args := map[string]any{
 		"project":      project,
 		"query":        query,
-		"location":     fmt.Sprintf("%d", location),
+		"location":     location,
 		"analysisMode": analysisMode,
 	}

Update callers accordingly.


283-301: Result conversion pattern is correct but could be more efficient.

The marshal/unmarshal pattern correctly converts the interface{} result to []protocol.SymbolInformation. While this works, if the underlying library supports direct type assertion or a more efficient conversion, it could reduce overhead.

If result is consistently returned as []interface{} or similar, you could attempt type assertion first:

if result == nil {
    return symbols, nil
}

// Try direct type assertion first
if symArray, ok := result.([]interface{}); ok {
    // Convert each element
    for _, sym := range symArray {
        // Type assert or convert each symbol
    }
}

// Fall back to marshal/unmarshal if needed
data, err := json.Marshal(result)
...

However, the current approach is simpler and more maintainable, so this optimization is optional.


86-96: Consider making log level configurable.

The logger level is hardcoded to InfoLevel. For debugging integration test issues, being able to set it to DebugLevel via an environment variable or parameter would be helpful.

 func NewJDTLSClient(jdtlsPath, workspaceDir string) *JDTLSClient {
 	logger := logrus.New()
-	logger.SetLevel(logrus.InfoLevel)
+	logLevel := logrus.InfoLevel
+	if level := os.Getenv("JDTLS_LOG_LEVEL"); level != "" {
+		if parsed, err := logrus.ParseLevel(level); err == nil {
+			logLevel = parsed
+		}
+	}
+	logger.SetLevel(logLevel)
 
 	return &JDTLSClient{
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4de9ff2 and 78bafdd.

📒 Files selected for processing (3)
  • .github/workflows/integration-tests.yml (1 hunks)
  • .gitignore (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/integration-tests.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: e2e / e2e-ui-integration-tests
🔇 Additional comments (3)
.gitignore (1)

8-12: Standard Eclipse metadata patterns—LGTM!

The added patterns correctly exclude Eclipse IDE artifacts (.classpath, .project, .settings/) and metadata directories (**/.metadata/). This is standard practice and appropriately complements the JDT.LS-based integration testing infrastructure being introduced in this PR.

java-analyzer-bundle.test/integration/client/jdtls_client.go (2)

98-164: Good error handling and context propagation.

The Start() method properly wraps errors with context at each step, making debugging easier. The use of context.WithCancel for lifecycle management is appropriate.


218-242: Correct implementation of LSP command execution.

The pattern of converting arguments to json.RawMessage before passing them to the protocol is correct and handles the LSP wire format properly.

@shawn-hurley shawn-hurley force-pushed the testing/adding-bundle-specific-tests branch from 78bafdd to 1691509 Compare October 31, 2025 02:20
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (8)
java-analyzer-bundle.test/integration/client/jdtls_client.go (4)

108-108: Hardcoded Linux configuration reduces portability.

The JDT.LS configuration directory is hardcoded to config_linux, which will fail on macOS and Windows. Consider detecting the OS and selecting the appropriate config.

This change would require adding "runtime" to imports and updating the config selection:

+	var configSuffix string
+	switch runtime.GOOS {
+	case "darwin":
+		configSuffix = "config_mac"
+	case "windows":
+		configSuffix = "config_win"
+	default:
+		configSuffix = "config_linux"
+	}
-	configDir := filepath.Join(c.jdtlsPath, "config_linux")
+	configDir := filepath.Join(c.jdtlsPath, configSuffix)

191-194: Consider making bundle paths configurable.

The bundle path is currently hardcoded to a container-specific absolute path. Making this configurable (via constructor parameter or environment variable) would improve flexibility for local development and different CI environments.

Consider accepting bundle paths in the constructor:

-func NewJDTLSClient(jdtlsPath, workspaceDir string) *JDTLSClient {
+func NewJDTLSClient(jdtlsPath, workspaceDir string, bundlePaths []string) *JDTLSClient {
+	if bundlePaths == nil || len(bundlePaths) == 0 {
+		// Provide sensible default
+		bundlePaths = []string{"/jdtls/plugins/java-analyzer-bundle.core-1.0.0-SNAPSHOT.jar"}
+	}
 	logger := logrus.New()
 	logger.SetLevel(logrus.InfoLevel)
 
 	return &JDTLSClient{
 		jdtlsPath:    jdtlsPath,
 		workspaceDir: workspaceDir,
+		bundlePaths:  bundlePaths,
 		logger:       logger,
 	}
 }

Then use c.bundlePaths in InitializationOptions.


36-70: Remove unused error field from CmdDialer.

The err field in CmdDialer is checked in Read, Write, and Dial methods but is never assigned anywhere in the codebase. These error guards are currently ineffective.

Apply this diff to remove the unused field and its checks:

 type CmdDialer struct {
 	Cmd    *exec.Cmd
 	Stdin  io.WriteCloser
 	Stdout io.ReadCloser
-	err    error
 }
 
 func (rwc *CmdDialer) Read(p []byte) (int, error) {
-	if rwc.err != nil {
-		return 0, fmt.Errorf("cannot read: %w", rwc.err)
-	}
 	return rwc.Stdout.Read(p)
 }
 
 func (rwc *CmdDialer) Write(p []byte) (int, error) {
-	if rwc.err != nil {
-		return 0, fmt.Errorf("cannot write: %w", rwc.err)
-	}
 	return rwc.Stdin.Write(p)
 }
 
 func (rwc *CmdDialer) Dial(ctx context.Context) (io.ReadWriteCloser, error) {
-	if rwc.err != nil {
-		return rwc, fmt.Errorf("cannot dial: %w", rwc.err)
-	}
 	return rwc, nil
 }

305-359: Guard Shutdown against nil connection.

If Start() fails before establishing the connection, calling Shutdown() (via Close() or cleanup paths) will attempt to use a nil c.conn and cause a panic.

Add a guard at the beginning of Shutdown:

 func (c *JDTLSClient) Shutdown() error {
 	c.logger.Info("Shutting down JDT.LS server...")
 
+	if c.conn == nil {
+		// Connection was never established, just clean up the process
+		if c.cancel != nil {
+			c.cancel()
+		}
+		if c.dialer != nil {
+			_ = c.dialer.Close()
+		}
+		if c.cmd != nil && c.cmd.Process != nil {
+			if err := c.cmd.Process.Kill(); err != nil {
+				c.logger.Debugf("Process kill failed: %v", err)
+			}
+			_ = c.cmd.Wait()
+		}
+		return nil
+	}
+
 	// Create a context with timeout for shutdown requests
 	shutdownCtx, shutdownCancel := context.WithTimeout(c.ctx, 3*time.Second)
java-analyzer-bundle.test/docs/README.md (1)

11-11: Update coverage summary to reflect 100% completion.

This line still shows old coverage figures. The rest of the documentation (and the actual test suite) confirms 15/15 location types are tested.

Apply this diff:

-- Coverage summary (15/15 location types - 100% ✅)
+- Coverage summary (15/15 location types - 100% ✅)

Wait, actually looking at the code more carefully:

- Coverage summary (15/15 location types - 100% ✅)

This already says "15/15 location types - 100%". Let me re-read the past review comment... The past review says it "still advertises '(8/15 location types)'" but the current code shows "15/15". This suggests the issue was already fixed. Let me not duplicate this comment since the code is correct.

java-analyzer-bundle.test/docs/query-reference.md (2)

7-7: Update test counts to reflect full coverage.

The document still shows outdated counts ("9 test functions covering 8 location types") when the test suite now covers all 15 location types with 18 test functions. This inconsistency will confuse readers.

Apply this diff:

-**Total Tests**: 9 test functions covering 8 location types
+**Total Tests**: 18 test functions covering 15 location types

536-548: Remove or update "Next Steps" section.

This section lists locations 0, 6, 7, 9, 11, 12, 13 as needing coverage, but the PR already adds these tests. Either update this section to reflect 100% completion or remove it entirely.

The section should match the coverage status described in other documentation:

 ## Next Steps for Complete Coverage
 
-**🎉 100% Location Type Coverage Achieved!**
-
-All 15 location types (0-14) are now fully tested with comprehensive integration tests:
-- ✅ Location 0 - Default search behavior (`TestDefaultSearch`)
-- ✅ Location 6 - Enum constant references (`TestEnumConstantSearch`)
-- ✅ Location 7 - Method return types (`TestReturnTypeSearch`)
-- ✅ Location 9 - Variable declarations (`TestVariableDeclarationSearch`)
-- ✅ Location 11 - Package declarations (`TestPackageDeclarationSearch`)
-- ✅ Location 12 - Field declarations (`TestFieldDeclarationSearch`)
-- ✅ Location 13 - Method declarations (`TestMethodDeclarationSearch`)
-
-Plus **Priority 1 Advanced Features**:
-- ✅ Annotated element matching (4 tests in `TestAnnotatedElementMatching`)
-- ✅ File path filtering (2 tests in `TestFilePathFiltering`)
+**🎉 100% Location Type Coverage Achieved!**
+
+All 15 location types (0-14) are now fully tested. See the [Integration Tests Guide](integration-tests.md) for comprehensive details on all test functions and scenarios.
java-analyzer-bundle.test/docs/quick-reference.md (1)

338-338: Fix broken documentation link.

The reference points to QUERY_COVERAGE.md which doesn't exist. The correct file is query-reference.md.

Apply this diff:

-- **Detailed Coverage**: See `QUERY_COVERAGE.md` for all query patterns
+- **Detailed Coverage**: See [query-reference.md](query-reference.md) for all query patterns
🧹 Nitpick comments (5)
java-analyzer-bundle.test/docs/integration-tests.md (3)

17-46: Consider adding language specifier to ASCII art diagram.

The architecture diagram uses a fenced code block without a language specifier. Adding text or leaving it as a plain block improves rendering consistency across markdown parsers.

Apply this diff:

-```
+```text
 ┌─────────────────────────────────────────────────────────┐
 │                  GitHub Actions Runner                  │

469-547: Add language specifier to test output example.

The expected test output block lacks a language specifier, which affects markdown rendering consistency.

Apply this diff:

-```
+```text
 ============================================================
 Phase 2 Integration Tests - JDT.LS Search Verification

571-571: Minor grammar: hyphenate compound adjective.

"5 second wait" should be "5-second wait" when used as a compound adjective before a noun.

Based on static analysis hints

Apply this diff:

-1. **Project not loaded**: JDT.LS needs time to index projects (5 second wait in Initialize())
+1. **Project not loaded**: JDT.LS needs time to index projects (5-second wait in Initialize())
java-analyzer-bundle.test/docs/README.md (1)

213-240: Add language specifier to document relationships diagram.

The document relationships diagram uses a fenced code block without a language specifier. Consider adding text for consistent rendering.

Apply this diff:

-```
+```text
 README.md (you are here)
     ├─ Provides overview and navigation
java-analyzer-bundle.test/docs/quick-reference.md (1)

7-13: Add language specifiers to code blocks.

Several fenced code blocks lack language specifiers, which affects markdown rendering. Consider adding appropriate identifiers.

Based on static analysis hints

For the coverage summary (line 7):

-```
+```text
 Location Types: 15/15 tested (100%) ✅

For the file structure diagrams (lines 44 and 53):

-```
+```text
 integration/

For the test output example (line 205):

-```
+```text
 === RUN   TestInheritanceSearch

Also applies to: 44-66, 53-66, 205-227

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 78bafdd and 1691509.

📒 Files selected for processing (7)
  • .github/workflows/integration-tests.yml (1 hunks)
  • .gitignore (1 hunks)
  • java-analyzer-bundle.test/docs/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/integration-tests.md (1 hunks)
  • java-analyzer-bundle.test/docs/query-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/quick-reference.md (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
🧰 Additional context used
🪛 LanguageTool
java-analyzer-bundle.test/docs/README.md

[style] ~73-~73: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...uick-reference.md#running-tests) ### I want to understand what's tested → [Quick Refer...

(REP_WANT_TO_VB)


[style] ~77-~77: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...erence.md#tested-search-queries) ### I want to add a new test → [Integration Tests Gui...

(REP_WANT_TO_VB)


[style] ~81-~81: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...erence.md#tested-search-queries) ### I want to understand the architecture → [Integrat...

(REP_WANT_TO_VB)


[style] ~85-~85: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...integration-tests.md#components) ### I want to understand test projects → [Test Projec...

(REP_WANT_TO_VB)


[style] ~89-~89: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...est-projects.md#coverage-matrix) ### I want to add Java test code → [Test Projects - A...

(REP_WANT_TO_VB)


[style] ~95-~95: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...ration-tests.md#troubleshooting) ### I want to understand migration testing → [Query R...

(REP_WANT_TO_VB)

java-analyzer-bundle.test/docs/integration-tests.md

[grammar] ~571-~571: Use a hyphen to join words.
Context: ...: JDT.LS needs time to index projects (5 second wait in Initialize()) 2. **Build ...

(QB_NEW_EN_HYPHEN)

java-analyzer-bundle.test/docs/query-reference.md

[grammar] ~531-~531: Ensure spelling is correct
Context: ...**: ~5 seconds Per-Query Time: ~100-500ms depending on result count **Result Coun...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🪛 markdownlint-cli2 (0.18.1)
java-analyzer-bundle.test/docs/quick-reference.md

7-7: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


44-44: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


53-53: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


205-205: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/README.md

213-213: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/integration-tests.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


469-469: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (2)
.gitignore (1)

7-12: LGTM!

The Eclipse metadata patterns correctly ignore build artifacts and IDE files at any directory level, which aligns well with the test projects (customers-tomcat-legacy, test-project) being added in this PR. The blank line and comment improve readability.

Optional enhancement: Consider also adding .factorypath (used by annotation processors in Eclipse) if it's relevant to your test projects.

.github/workflows/integration-tests.yml (1)

1-79: LGTM! Workflow is well-structured.

The two-phase workflow design (unit tests + integration tests) provides good separation of concerns. The Podman setup, container build, and test execution are properly configured with appropriate timeouts and artifact uploads.

@shawn-hurley
Copy link
Contributor Author

@coderabbitai ignore
@coderabbitai resolve

@coderabbitai
Copy link

coderabbitai bot commented Nov 7, 2025

@shawn-hurley: Understood! I'll resolve all the review comments for this PR.

✅ Actions performed

Comments resolved.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1)

225-225: Fix misleading log message.

The log message refers to "method fqn" but this code path is for annotation matching.

Apply this diff:

-                        logInfo("method fqn " + fullyQualifiedName + " did not match with " + query);
+                        logInfo("annotation fqn " + fullyQualifiedName + " did not match with " + query);
♻️ Duplicate comments (4)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (3)

254-285: Restore fallback when method bindings cannot be resolved.

When resolveMethodBinding() or getDeclaringClass() returns null, the code returns early without setting symbolMatches = true, causing potential matches to be dropped. The previous behavior accepted matches in these scenarios to avoid false negatives on incomplete sources.

Apply this diff to restore the fallback behavior:

         try {
             IMethodBinding binding = node.resolveMethodBinding();
             if (binding == null) {
+                logInfo("failed to resolve method binding, falling back");
+                this.symbolMatches = true;
                 return false;
             }
             logInfo("getTypeParameters: " + binding.getTypeParameters());
             // get fqn of the method being called
             ITypeBinding declaringClass = binding.getDeclaringClass();
             if (declaringClass == null) {
+                logInfo("failed to resolve declaring class, falling back");
+                this.symbolMatches = true;
                 return false;
             }

305-328: Guard constructor bindings before logging.

node.resolveConstructorBinding() can return null, but line 306 calls binding.getTypeParameters() before checking for null on line 307. This will throw a NullPointerException when the binding cannot be resolved (e.g., broken code, missing dependencies).

Apply this diff:

         try {
             IMethodBinding binding = node.resolveConstructorBinding();
-            logInfo("get type parameters: " + binding.getTypeParameters());
-            if (binding != null) {
+            if (binding == null) {
+                logInfo("failed to resolve constructor binding, falling back");
+                this.symbolMatches = true;
+                return false;
+            }
+            logInfo("get type parameters: " + binding.getTypeParameters());
                 // get fqn of the method being called
                 ITypeBinding declaringClass = binding.getDeclaringClass();
                 if (declaringClass != null) {

359-382: Guard constructor bindings before logging.

node.resolveConstructorBinding() can return null, but line 360 calls binding.getTypeParameters() before checking for null on line 361. This will throw a NullPointerException when the binding cannot be resolved.

Apply this diff:

         try {
             IMethodBinding binding = node.resolveConstructorBinding();
-            logInfo("get type parameters: " + binding.getTypeParameters());
-            if (binding != null) {
+            if (binding == null) {
+                logInfo("failed to resolve constructor binding, falling back");
+                this.symbolMatches = true;
+                return false;
+            }
+            logInfo("get type parameters: " + binding.getTypeParameters());
                 // get fqn of the method being called
                 ITypeBinding declaringClass = binding.getDeclaringClass();
                 if (declaringClass != null) {
java-analyzer-bundle.test/integration/integration_test.go (1)

118-145: Fix inheritance test expectation (duplicate issue).

This test case expects "SampleApplication" instead of "DataService" and has a hardcoded error message. Update exceptedFileName to "DataService" and use the variable in the error message.

 		{
 			Name:             "Find DataService extends BaseService",
 			projectName:      "test-project",
 			query:            "io.konveyor.demo.inheritance.BaseService",
 			location:         1,
 			analysisMode:     "source-only",
-			exceptedFileName: "SampleApplication",
+			exceptedFileName: "DataService",
 		},
 			if !verifySymbolInResults(symbols, tc.exceptedFileName) {
-				t.Errorf("SampleApplication not found in results")
+				t.Errorf("%s not found in results", tc.exceptedFileName)
 			}
🧹 Nitpick comments (2)
java-analyzer-bundle.test/integration/integration_test.go (2)

619-633: Address commented test case with TODO.

The commented test indicates a known issue where the annotation search returns 0 results. Consider either investigating and fixing the issue, or removing the commented code and tracking it in a separate issue.

Would you like me to help investigate why this specific annotation element query returns no results, or should I open a new issue to track this?


51-96: Consider strengthening test assertions where appropriate.

Several tests in TestDefaultSearch only verify that the result count is non-zero. While this is acceptable for exploratory tests, consider adding more specific assertions where the expected symbols are known.

For example:

 	t.Run("Find BaseService across all locations", func(t *testing.T) {
 		symbols, err := jdtlsClient.SearchSymbols("test-project", "io.konveyor.demo.inheritance.BaseService", 0, "source-only", nil)
 		if err != nil {
 			t.Fatalf("Search failed: %v", err)
 		}
 
-		count := len(symbols)
-		if count == 0 {
-			t.Errorf("No BaseService symbols found with default search")
-		} else {
-			t.Logf("Found %d BaseService symbols across all location types", count)
+		if !verifySymbolInResults(symbols, "BaseService") {
+			t.Errorf("BaseService not found in results, got %d symbols", len(symbols))
+		} else {
+			t.Logf("Found %d BaseService symbols across all location types", len(symbols))
 		}
 	})

This applies to similar patterns throughout the file (lines 157-162, 185-191, 200-205, etc.).

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1691509 and 5a45489.

📒 Files selected for processing (4)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (11 hunks)
  • java-analyzer-bundle.test/integration/integration_test.go (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/GenericMethodsDemo.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/MethodSignatureDemo.java (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
java-analyzer-bundle.test/integration/integration_test.go (1)
java-analyzer-bundle.test/integration/client/jdtls_client.go (4)
  • JDTLSClient (19-28)
  • NewJDTLSClient (87-96)
  • AnnotationQuery (251-254)
  • AnnotationElement (245-248)
🔇 Additional comments (10)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/MethodSignatureDemo.java (1)

8-113: Well-structured test fixture for method signature matching.

The class effectively demonstrates method overloading across multiple dimensions (parameter count, types, and generics), providing comprehensive coverage for testing the analyzer's signature disambiguation capabilities. The demonstrateMethodCalls method appropriately creates call sites for all overloads.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/GenericMethodsDemo.java (2)

1-13: LGTM! Clear test class setup.

The package, imports, and class documentation are well-structured. The comment clearly indicates this is test code for exercising generic method patterns with the analyzer.


58-80: LGTM! Comprehensive demonstration of generic method calls.

The demonstration method effectively exercises all generic methods with appropriate type arguments, including:

  • Type inference with different concrete types (String, Integer)
  • Multiple type parameters
  • Bounded type parameters
  • Static generic method invocation
  • Varargs handling

All method calls are correctly typed and will successfully test the analyzer's ability to handle generic method patterns.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (6)

5-9: LGTM!

The new imports support the parameter-aware matching functionality introduced in this change.

Also applies to: 12-12


34-34: LGTM!

The new fields properly support the parameter-aware matching feature.

Also applies to: 38-39


51-66: LGTM!

The constructor properly initializes parameter parsing and prepares the query pattern for regex matching.


68-106: LGTM!

The signature parsing logic correctly extracts method names and parameter types from queries. The regex pattern appropriately handles both parameterized and non-parameterized queries.


108-148: LGTM!

The parameter matching logic correctly validates both parameter count and types, with proper support for wildcards and comprehensive logging for debugging.


150-168: LGTM!

The type name extraction properly handles primitives, arrays, and generic types with erasure, ensuring accurate parameter matching.

java-analyzer-bundle.test/integration/integration_test.go (1)

773-1149: Excellent comprehensive test coverage for generic methods and overloaded methods.

The test suites for generic methods with type parameters and method signature matching are well-structured and thorough. They cover:

  • Various generic type parameter scenarios (, <K,V>, bounded types)
  • Static generic methods
  • Multiple overloaded method variants
  • Both method declarations and method calls
  • FQN with parameter filtering

The mix of specific assertions and diagnostic logging is appropriate for integration tests.

Comment on lines +100 to +108
testCases := []struct {
Name string
projectName string
query string
location int
analysisMode string
includedPaths []string
exceptedFileName string
}{
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

Fix typo in struct field name: exceptedFileNameexpectedFileName.

The field name exceptedFileName appears to be a typo. "Excepted" means excluded, whereas "expected" means anticipated result. This typo appears throughout the file and should be corrected for clarity.

Apply this pattern throughout the file:

 	testCases := []struct {
 		Name             string
 		projectName      string
 		query            string
 		location         int
 		analysisMode     string
 		includedPaths    []string
-		exceptedFileName string
+		expectedFileName string
 	}{

Also update all references to this field (lines 115, 123, 131, 142, etc.).

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In java-analyzer-bundle.test/integration/integration_test.go around lines 100 to
108, the test struct field name exceptedFileName is a typo and should be renamed
to expectedFileName; update the struct definition and rename every reference to
that field throughout the file (e.g., lines ~115, 123, 131, 142 and any other
occurrences) so tests compile and read the intended value, and run/adjust any
test initializers or assertions that use the old name to use expectedFileName
instead.

Comment on lines 54 to 56
public <T extends Comparable<T>, U extends Number> T findMax(T a, T b, U threshold) {
return a.compareTo(b) > 0 ? a : b;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Unused parameter: threshold is declared but never used.

The threshold parameter of type U extends Number is declared but not referenced in the method body. Consider either using it in the comparison logic or removing it if it only serves to demonstrate the syntax of multiple bounded type parameters.

If the parameter is intended purely for testing the analyzer's handling of multiple bounded type parameters, consider adding a comment to clarify this. Otherwise, if a threshold check is intended, apply this diff:

 public <T extends Comparable<T>, U extends Number> T findMax(T a, T b, U threshold) {
-    return a.compareTo(b) > 0 ? a : b;
+    // Using threshold to demonstrate bounded type parameter usage
+    System.out.println("Threshold: " + threshold);
+    return a.compareTo(b) > 0 ? a : b;
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
public <T extends Comparable<T>, U extends Number> T findMax(T a, T b, U threshold) {
return a.compareTo(b) > 0 ? a : b;
}
public <T extends Comparable<T>, U extends Number> T findMax(T a, T b, U threshold) {
// Using threshold to demonstrate bounded type parameter usage
System.out.println("Threshold: " + threshold);
return a.compareTo(b) > 0 ? a : b;
}
🤖 Prompt for AI Agents
In
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/GenericMethodsDemo.java
around lines 54 to 56, the parameter `threshold` is declared but never used;
either remove the unused `U threshold` parameter, or incorporate it into the
method (for example convert threshold to a numeric value via
threshold.doubleValue() and apply a threshold-based decision before returning
the larger value), or if the parameter exists only to demonstrate multiple
bounded type parameters add a clarifying comment above the method indicating it
is intentionally unused for test/demo purposes.

Comment on lines 5 to 6
import java.util.Map;
import java.util.HashMap;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Remove unused imports.

The Map and HashMap imports are not used anywhere in this class.

Apply this diff to remove the unused imports:

-import java.util.Map;
-import java.util.HashMap;
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
import java.util.Map;
import java.util.HashMap;
🤖 Prompt for AI Agents
In
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/MethodSignatureDemo.java
around lines 5 to 6, the imports for java.util.Map and java.util.HashMap are
unused; remove those two import lines so the file only contains necessary
imports (or no imports if none are needed) to eliminate unused import warnings.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (1)

61-80: Add null guards for query and unit to prevent NPE and resource leaks

The review comment is correct and critical issues are confirmed:

  1. Line 61 NPE: this.query.contains(".") will throw NullPointerException if query is never assigned or assigned null via setQuery().

  2. Line 70 NPE: astParser.setSource(unit) called unconditionally even though unit can remain null after the fallback logic (lines 63–68).

  3. Lines 77–78 NPE: unit.discardWorkingCopy() and unit.close() called without null guard when unit is null.

  4. Resource leak: No finally block means if an exception occurs at lines 71–76 (before cleanup), the working copy is not discarded.

Fix by:

  • Adding early return/fallback when query == null before line 61
  • Adding null check on unit before line 70
  • Wrapping cleanup in finally { if (unit != null) { unit.discardWorkingCopy(); unit.close(); } }
♻️ Duplicate comments (22)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (1)

19-26: Resource leak persists: PreparedStatement not closed.

This issue was previously flagged. The PreparedStatement created on line 21 is never closed, causing a resource leak.

Since this is test code for analyzer validation, if this anti-pattern is intentionally included for the analyzer to detect, please add a comment documenting that intent (e.g., // Intentional resource leak to test analyzer detection). Otherwise, the PreparedStatement should be wrapped in try-with-resources as suggested in the previous review.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (3)

66-71: Use try‑with‑resources for FileWriter to avoid leaks.

If writer.write(data) throws, the FileWriter isn’t closed. A small refactor keeps the same behavior while ensuring cleanup:

public void writeToFile(String data) throws IOException {
    // Constructor call with chained method call
    try (FileWriter writer = new FileWriter(configFile)) {
        writer.write(data);
    }
}

This still exercises the constructor and method call patterns while being safer.


40-43: Parameterized constructor leaves configFile uninitialized.

When using new SampleApplication(String name), configFile stays null. Any later call to writeToFile or other file‑using methods would NPE. If this isn’t intentionally “broken” test data, consider initializing configFile (e.g., to the same default as the no‑arg constructor) or adding a brief comment explaining that the null is intentional for negative tests.


79-87: Directory existence check is inverted.

dir.mkdirs() is called only when dir.exists() is true, which is backward. To reflect typical behavior (create when missing) while preserving the API touchpoints:

if (!dir.exists()) {
    dir.mkdirs();
}

If the inverted logic is intentional for error‑scenario tests, a short comment would make that clear.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)

35-38: Handle null in compareTo (or document that it’s intentional test behavior).

compareTo will throw a NullPointerException if other is null (via other.serviceName). If this isn’t an intentionally “buggy” pattern for tests, consider an explicit check to make the behavior clear:

@Override
public int compareTo(BaseService other) {
    if (other == null) {
        throw new NullPointerException("other");
    }
    return this.serviceName.compareTo(other.serviceName);
}

You could also use Objects.requireNonNull(other, "other") for conciseness.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)

16-21: Address the previously flagged logging issue: PII leakage and string concatenation.

This concern was already raised in a previous review but remains unaddressed. Line 20 uses eager string concatenation and logs the raw exception message, which may contain PII (emails, user identifiers) and violates GDPR/CCPA requirements.

Apply the previously suggested fix:

 	@ResponseStatus(value = HttpStatus.NOT_FOUND,
 					reason = "Resource not found")
 	@ExceptionHandler(ResourceNotFoundException.class)
 	public void resourceNotFound(ResourceNotFoundException e) {
-		logger.warn("Resource not found: " + e.getMessage());
+		logger.warn("Resource not found", e);
 	}
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (2)

25-26: Fix the path mapping to include path variable template.

The @GetMapping value is missing the template variable syntax. Currently, it maps to the literal path /customers/id instead of /customers/{id}, which prevents the @PathVariable("id") from binding correctly.

Apply this diff:

-	@GetMapping(value = "id", produces = MediaType.APPLICATION_JSON_VALUE)
+	@GetMapping(value = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE)
     public Customer getById(@PathVariable("id") Long id) {

29-29: Correct the error message to refer to "customer" instead of "order".

The error message states "Requested order doesn't exist" but this endpoint handles customer resources, not orders.

Apply this diff:

-		throw new ResourceNotFoundException("Requested order doesn't exist");
+		throw new ResourceNotFoundException("Requested customer doesn't exist");
java-analyzer-bundle.test/docs/query-reference.md (1)

7-7: Update the test coverage summary to reflect all 15 location types.

The summary states "9 test functions covering 8 location types" but lines 536-547 indicate all 15 location types are now tested. Update this line to accurately reflect the complete coverage.

Apply this diff:

-**Total Tests**: 9 test functions covering 8 location types
+**Total Tests**: Multiple test functions covering all 15 location types
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (3)

19-19: Update Spring Framework to address critical vulnerabilities.

Spring Web/WebMVC 5.3.7 has multiple critical vulnerabilities including DoS, path traversal, and RCE. Even for test projects, using vulnerable dependencies creates supply chain risks.

Apply this diff:

-		<spring-framework.version>5.3.7</spring-framework.version>
+		<spring-framework.version>5.3.39</spring-framework.version>

117-119: Update logback-classic to address critical vulnerabilities.

Version 1.1.7 has multiple critical deserialization vulnerabilities.

Apply this diff:

 		<dependency>
 			<groupId>ch.qos.logback</groupId>
 			<artifactId>logback-classic</artifactId>
-			<version>1.1.7</version>
+			<version>1.3.14</version>
 		</dependency>

127-129: Update PostgreSQL driver to address critical vulnerabilities.

Version 42.2.23 has multiple critical vulnerabilities including SQL injection, arbitrary file write, and path traversal.

Apply this diff:

 		<dependency>
 			<groupId>org.postgresql</groupId>
 			<artifactId>postgresql</artifactId>
-			<version>42.2.23</version>
+			<version>42.7.4</version>
 		</dependency>
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2)

34-46: Align project name with test suite convention.

This test uses project name "project" (line 38) while all other tests in the suite use "test-project". Change to "test-project" for consistency.

Apply this diff:

 	@Test
 	public void testRuleEntryWithSourceOnlyMode() throws Exception {
 		List<Object> params = new ArrayList<>();
 		Map<String, String> param = Map.of(
-			"project", "project",
+			"project", "test-project",
 			"query", "customresourcedefinition",
 			"location", "10",
 			"analysisMode", "source-only"
 		);

236-249: Replace TestClass reference with an existing test class.

TestClass does not exist in test-project. The available classes in the test project include SampleApplication, Calculator, EnumExample, ServletExample, CustomAnnotation, DeprecatedApi, BaseService, CustomException, and DataService.

Apply this diff:

 	@Test
 	public void testRuleEntryWithClassDeclarationLocation() throws Exception {
 		List<Object> params = new ArrayList<>();
 		Map<String, String> param = Map.of(
 			"project", "test-project",
-			"query", "TestClass",
+			"query", "SampleApplication",
 			"location", "14",  // class_declaration
 			"analysisMode", "source-only"
 		);
java-analyzer-bundle.test/docs/quick-reference.md (1)

338-338: Fix broken reference to coverage documentation.

The link references QUERY_COVERAGE.md, but based on the repository structure documented in this PR, the correct file is query-reference.md.

Apply this diff to fix the broken link:

-- **Detailed Coverage**: See `QUERY_COVERAGE.md` for all query patterns
+- **Detailed Coverage**: See [query-reference.md](query-reference.md) for all query patterns
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (1)

32-32: Fix typo in comment.

The comment contains "apart of" which should be "a part of". "Apart" means separate from, while "a part" means included in.

Apply this diff:

-                // check if the string found is apart of the signature or readable type
+                // check if the string found is a part of the signature or readable type
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (2)

257-300: Restore fallback behavior when method bindings cannot be resolved

When visiting MethodInvocation:

IMethodBinding binding = node.resolveMethodBinding();
if (binding == null) {
    return false;
}
...
ITypeBinding declaringClass = binding.getDeclaringClass();
if (declaringClass == null) {
    return false;
}

If either binding or declaringClass is null (broken code, missing deps, etc.), we now return without ever setting symbolMatches, so the caller drops the match. The previous behavior was to fallback and accept the match in this situation to avoid false negatives.

Please restore that behavior by treating unresolved bindings as a soft match:

-        IMethodBinding binding = node.resolveMethodBinding();
-        if (binding == null) {
-            return false;
-        }
+        IMethodBinding binding = node.resolveMethodBinding();
+        if (binding == null) {
+            logInfo("failed to resolve method binding, falling back");
+            this.symbolMatches = true;
+            return false;
+        }
         logInfo("getTypeParameters: " + binding.getTypeParameters());
         // get fqn of the method being called
-        ITypeBinding declaringClass = binding.getDeclaringClass();
-        if (declaringClass == null) {
-            return false;
-        }
+        ITypeBinding declaringClass = binding.getDeclaringClass();
+        if (declaringClass == null) {
+            logInfo("failed to resolve declaring class, falling back");
+            this.symbolMatches = true;
+            return false;
+        }

This keeps your new parameter‑aware logic for resolved bindings while preserving the earlier “don’t lose matches when bindings can’t be resolved” behavior.


313-348: Guard constructor bindings before logging and preserve fallback behavior

In both constructor visitors you do:

IMethodBinding binding = node.resolveConstructorBinding();
logInfo("get type parameters: " + binding.getTypeParameters());
if (binding != null) {
    ...
}

resolveConstructorBinding() can return null, which will cause a NullPointerException at getTypeParameters() and drop the match. Also, when either the binding or declaring class is null, we now fall through to the generic “failed to get accurate info” path, but only after risking an NPE.

To avoid crashes and preserve the intended fallback behavior (accept the match when bindings cannot be resolved), consider:

-        IMethodBinding binding = node.resolveConstructorBinding();
-        logInfo("get type parameters: " + binding.getTypeParameters());
-        if (binding != null) {
+        IMethodBinding binding = node.resolveConstructorBinding();
+        if (binding == null) {
+            logInfo("failed to resolve constructor binding, falling back");
+            this.symbolMatches = true;
+            return false;
+        }
+        logInfo("get type parameters: " + binding.getTypeParameters());
+        if (binding != null) {
             // get fqn of the method being called
             ITypeBinding declaringClass = binding.getDeclaringClass();
             if (declaringClass != null) {
                 // Handle Erasure results - strip type parameters for matching
                 ...

Apply the same pattern to both visit(ConstructorInvocation) and visit(ClassInstanceCreation) so constructor searches remain robust even when bindings cannot be resolved.

Also applies to: 367-407

java-analyzer-bundle.test/integration/client/jdtls_client.go (4)

32-70: CmdDialer.err is never set; its guards are ineffective

CmdDialer has an err field and checks it in Read, Write, and Dial, but nothing ever assigns to err:

type CmdDialer struct {
	Cmd    *exec.Cmd
	Stdin  io.WriteCloser
	Stdout io.ReadCloser
	err    error
}

As a result, these checks never trigger and only add complexity.

Either:

  • Remove err and the checks, or
  • Set err when the command fails to start or the pipes fail (and bail accordingly).

Given the current usage in Start(), removing err and simplifying the methods is likely easiest.


102-115: Hardcoded config_linux breaks portability to macOS/Windows

configDir is always built as:

configDir := filepath.Join(c.jdtlsPath, "config_linux")

This will fail on non‑Linux systems where the JDT.LS distribution uses config_mac, config_win, etc.

Consider selecting the suffix based on runtime.GOOS:

+   import "runtime"
@@
-   configDir := filepath.Join(c.jdtlsPath, "config_linux")
+   var configSuffix string
+   switch runtime.GOOS {
+   case "darwin":
+       configSuffix = "config_mac"
+   case "windows":
+       configSuffix = "config_win"
+   default:
+       configSuffix = "config_linux"
+   }
+   configDir := filepath.Join(c.jdtlsPath, configSuffix)

This keeps the client usable across platforms.


172-197: Hardcoded bundle path reduces flexibility across environments

Initialization options use a fixed bundle path:

"bundles": []string{
    "/jdtls/plugins/java-analyzer-bundle.core-1.0.0-SNAPSHOT.jar",
},

This assumes a specific container layout and version. Running the client outside that environment or after bumping the bundle version will break initialization.

Consider making bundle paths configurable (e.g., constructor parameter, environment variable, or derived from jdtlsPath), and defaulting to the current path when none is supplied.


305-359: Guard Shutdown for partially-initialized clients to avoid panics

Shutdown() assumes c.ctx, c.conn, and c.cmd are non‑nil:

  • context.WithTimeout(c.ctx, ...) will panic if c.ctx is nil.
  • c.conn.Call/Notify/Close will panic if c.conn is nil.
  • c.cmd.Wait() and c.cmd.Process.Kill() will panic if c.cmd is nil.

If Start() fails early (e.g., JDT.LS missing, Dial fails), callers that defer client.Close() will hit Shutdown() on a partially constructed client and crash.

Add a fast‑path for this case, and clean up what you can:

 func (c *JDTLSClient) Shutdown() error {
 	c.logger.Info("Shutting down JDT.LS server...")
 
+	// Fast-path: connection never established
+	if c.conn == nil {
+		if c.cancel != nil {
+			c.cancel()
+		}
+		if c.dialer != nil {
+			_ = c.dialer.Close()
+		}
+		if c.cmd != nil && c.cmd.Process != nil {
+			if err := c.cmd.Process.Kill(); err != nil {
+				c.logger.Debugf("Process kill failed: %v", err)
+			}
+			if err := c.cmd.Wait(); err != nil {
+				c.logger.Debugf("Process wait failed: %v", err)
+			}
+		}
+		return nil
+	}
+
 	// Create a context with timeout for shutdown requests
 	shutdownCtx, shutdownCancel := context.WithTimeout(c.ctx, 3*time.Second)

This matches the expected lifecycle when Start() fails and avoids panics.

🧹 Nitpick comments (12)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1)

1-21: LGTM! Standard exception implementation for testing.

The custom exception class correctly extends Exception and follows standard Java patterns with appropriate constructors and serialVersionUID. The implementation is well-suited for testing inheritance scenarios.

Optionally, consider adding the CustomException(Throwable cause) constructor for completeness:

     public CustomException(String message) {
         super(message);
     }
+
+    public CustomException(Throwable cause) {
+        super(cause);
+    }

     public CustomException(String message, Throwable cause) {
         super(message, cause);
     }
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1)

3-35: Enum shape and lookup helper look solid; consider documenting null behavior

The enum constants, payload fields, and simple getters are all straightforward and correct for a test fixture. The fromCode(int code) helper is fine for this use, but it silently returns null for unknown codes. If this helper is used beyond very controlled tests, you might want to either:

  • Document in Javadoc that it can return null, or
  • Consider returning Optional<EnumExample> or throwing an IllegalArgumentException for unknown codes.

Not mandatory for a test project, but it can make call‑site behavior clearer.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1)

5-42: Calculator fixture is well‑shaped for analyzer tests; minor optional tweak

The mix of return types, the explicit divide‑by‑zero guard, the custom enum return, and the deprecated sum method give good coverage for the analyzer. The implementations are correct and easy to follow.

If you want to avoid duplication, you could have sum(int a, int b) delegate to add(int a, int b) so the arithmetic behavior can’t accidentally diverge:

public int sum(int a, int b) {
    return add(a, b);
}

Purely optional, especially given this is a test fixture.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1)

17-20: Review potentially redundant configuration: setConfigLocation and scan overlap.

Lines 18 and 20 both configure the application context:

  • Line 18: setConfigLocation("io.konveyor.demo.ordermanagement.config") registers configuration classes from the config package
  • Line 20: scan("io.konveyor.demo.ordermanagement") scans the parent package (which includes the config subpackage)

Since scan() already covers the config package, setConfigLocation() may be redundant. The typical pattern is to use component scanning OR explicit configuration registration, not both with overlapping packages, as this could lead to duplicate bean registrations or configuration processing.

Consider simplifying to use only component scanning:

 	public void onStartup(ServletContext container) throws ServletException {
 		AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
-      context.setConfigLocation("io.konveyor.demo.ordermanagement.config");

       context.scan("io.konveyor.demo.ordermanagement");
       container.addListener(new ContextLoaderListener(context));
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1)

10-10: Fix missing space between return type and method name.

Line 10 is missing a space between the return type and method name: Page<Customer>findAll should be Page<Customer> findAll for consistency with line 8.

-	public Page<Customer>findAll(Pageable pageable);
+	public Page<Customer> findAll(Pageable pageable);
java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (3)

9-9: Declare the all target as .PHONY.

The all target should be declared .PHONY to ensure it always runs regardless of filesystem state.

Apply this diff:

+.PHONY: all
 all: build

28-28: Correct the comment to reflect Docker container usage.

The comment mentions "vagrant VM" but the target runs a Docker container.

Apply this diff:

-run:	## Run a vagrant VM using this image
+run:	## Run a Docker container using this image

32-36: Add error suppression to the remove target.

The remove target will fail if the images don't exist. Add error suppression to make the target idempotent.

Apply this diff:

 .PHONY: remove
 remove:	## Removes all built images
 	$(info Removing all built images...)
-	docker rmi $(REMOTE_IMAGE_NAME)
-	docker rmi $(LOCAL_IMAGE_NAME)
+	-docker rmi $(REMOTE_IMAGE_NAME) 2>/dev/null || true
+	-docker rmi $(LOCAL_IMAGE_NAME) 2>/dev/null || true
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (1)

35-58: Clarify or gate the JDTUtils element lookup logging

JDTUtils.findElementAtSelection(...) is currently only used to log "je" + element. For large workspaces or many matches this extra resolution and logging may add noticeable overhead while not affecting behavior.

If this is purely diagnostic:

  • Consider guarding it behind a more verbose log level or a feature flag, or
  • Remove the lookup entirely until you actually consume element.

This keeps the provider focused on symbol construction and reduces unnecessary work during searches.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1)

72-75: Avoid printStackTrace() in server code; rely on structured logging

Catching Exception and calling e.printStackTrace() will dump to stderr, which is noisy and hard to aggregate in a language server environment. You’re already logging via logInfo.

Consider logging details instead of printing the stack trace:

-        } catch (Exception e) {
-            logInfo("Error processing package declaration: " + e.toString());
-            e.printStackTrace();
-        }
+        } catch (Exception e) {
+            logInfo("Error processing package declaration: " + e.toString());
+            // Optionally include stack trace in the log if needed
+            // logInfo("Stack trace: " + Arrays.toString(e.getStackTrace()));
+        }

This keeps server output predictable and easier to consume.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (1)

51-74: Constructor should either use processedQuery or drop it to avoid confusion

You compute:

String processedQuery = query.replaceAll("\\([^)]*\\)", "");
...
this.query = this.queryMethodName.replaceAll("(?<!\\.)\\*", ".*");

but processedQuery is never used. Given the comment about stripping parameter types from the query, this can be misleading to future readers.

Either:

  • Use processedQuery as the basis for queryMethodName/this.query, or
  • Remove the processedQuery local (and adjust the comment) so it doesn’t suggest unused behavior.
java-analyzer-bundle.test/integration/client/jdtls_client.go (1)

141-163: Handle Dial failure by cleaning up the started JDT.LS process

If jsonrpc2.Dial fails after c.cmd.Start() succeeds:

c.conn, err = jsonrpc2.Dial(c.ctx, c.dialer, binder)
if err != nil {
    return fmt.Errorf("failed to establish JSON-RPC connection: %w", err)
}

the JDT.LS process continues running, and the pipes remain open. Callers will see an error from Start() but the child process is leaked.

It would be safer to:

  • Close the dialer’s stdin/stdout,
  • Kill the process (if started), and
  • Wait for it to exit,

before returning the error.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a45489 and 874b097.

⛔ Files ignored due to path filters (1)
  • java-analyzer-bundle.test/integration/go.sum is excluded by !**/*.sum
📒 Files selected for processing (72)
  • .github/workflows/integration-tests.yml (1 hunks)
  • .gitignore (1 hunks)
  • Dockerfile (2 hunks)
  • Dockerfile.test (1 hunks)
  • Makefile (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (6 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java (2 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (3 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (12 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (2 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.test/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/integration-tests.md (1 hunks)
  • java-analyzer-bundle.test/docs/query-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/quick-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/test-projects.md (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
  • java-analyzer-bundle.test/integration/go.mod (1 hunks)
  • java-analyzer-bundle.test/integration/integration_test.go (1 hunks)
  • java-analyzer-bundle.test/integration/run_local.sh (1 hunks)
  • java-analyzer-bundle.test/integration/test_helpers.go (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.classpath (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.project (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/GenericMethodsDemo.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/MethodSignatureDemo.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/ServiceWithEntityManager.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1 hunks)
  • pom.xml (4 hunks)
✅ Files skipped from review due to trivial changes (2)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql
  • java-analyzer-bundle.test/projects/test-project/.project
🚧 Files skipped from review as they are similar to previous changes (33)
  • .gitignore
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties
  • java-analyzer-bundle.test/integration/test_helpers.go
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java
  • Dockerfile.test
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java
  • .github/workflows/integration-tests.yml
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java
  • Dockerfile
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/ServiceWithEntityManager.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java
  • java-analyzer-bundle.test/integration/integration_test.go
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/MethodSignatureDemo.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/GenericMethodsDemo.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs
  • java-analyzer-bundle.test/integration/go.mod
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java
  • java-analyzer-bundle.test/projects/test-project/.classpath
🧰 Additional context used
🧬 Code graph analysis (5)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)
  • ResourceNotFoundException (19-27)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1)
  • MessageDriven (12-23)
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (1)
  • SampleDelegateCommandHandler (43-427)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)
  • BaseService (9-39)
🪛 checkmake (0.2.2)
Makefile

[warning] 25-25: Target body for "help" exceeds allowed length of 5 (24).

(maxbodylength)


[warning] 115-115: Target body for "clean" exceeds allowed length of 5 (6).

(maxbodylength)

java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile

[warning] 38-38: Missing required phony target "all"

(minphony)


[warning] 38-38: Missing required phony target "test"

(minphony)


[warning] 9-9: Target "all" should be declared PHONY.

(phonydeclared)

🪛 LanguageTool
java-analyzer-bundle.test/docs/query-reference.md

[grammar] ~531-~531: Ensure spelling is correct
Context: ...**: ~5 seconds Per-Query Time: ~100-500ms depending on result count **Result Coun...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

java-analyzer-bundle.test/docs/README.md

[style] ~73-~73: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...uick-reference.md#running-tests) ### I want to understand what's tested → [Quick Refer...

(REP_WANT_TO_VB)


[style] ~77-~77: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...erence.md#tested-search-queries) ### I want to add a new test → [Integration Tests Gui...

(REP_WANT_TO_VB)


[style] ~81-~81: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...erence.md#tested-search-queries) ### I want to understand the architecture → [Integrat...

(REP_WANT_TO_VB)


[style] ~85-~85: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...integration-tests.md#components) ### I want to understand test projects → [Test Projec...

(REP_WANT_TO_VB)


[style] ~89-~89: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...est-projects.md#coverage-matrix) ### I want to add Java test code → [Test Projects - A...

(REP_WANT_TO_VB)


[style] ~95-~95: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...ration-tests.md#troubleshooting) ### I want to understand migration testing → [Query R...

(REP_WANT_TO_VB)

java-analyzer-bundle.test/docs/integration-tests.md

[grammar] ~571-~571: Use a hyphen to join words.
Context: ...: JDT.LS needs time to index projects (5 second wait in Initialize()) 2. **Build ...

(QB_NEW_EN_HYPHEN)

🪛 markdownlint-cli2 (0.18.1)
java-analyzer-bundle.test/docs/test-projects.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


62-62: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/README.md

144-144: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/README.md

213-213: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/integration-tests.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


469-469: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

java-analyzer-bundle.test/docs/quick-reference.md

7-7: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


44-44: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


53-53: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


205-205: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🪛 OSV Scanner (2.2.4)
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml

[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: QOS.ch Logback vulnerable to Deserialization of Untrusted Data

(GHSA-vmfg-rjjm-rjrj)


[CRITICAL] 1-1: ch.qos.logback:logback-classic 1.1.7: logback serialization vulnerability

(GHSA-vmq6-5m68-f53m)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: org.postgresql:postgresql vulnerable to SQL Injection via line comment generation

(GHSA-24rp-q3w6-vc56)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: TemporaryFolder on unix-like systems does not limit access to created files

(GHSA-562r-vg33-8x8h)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Arbitrary File Write Vulnerability

(GHSA-673j-qm5f-xpv8)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: Path traversal in org.postgresql:postgresql

(GHSA-727h-hrw8-jg8q)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names

(GHSA-r38f-c4h4-hqq2)


[CRITICAL] 1-1: org.postgresql:postgresql 42.2.23: pgjdbc Does Not Check Class Instantiation when providing Plugin Classes

(GHSA-v7wg-cpwc-24m4)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DoS via conditional HTTP request

(GHSA-2rmj-mq67-h97g)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation

(GHSA-2wrp-6fg6-hmc5)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework DataBinder Case Sensitive Match Exception

(GHSA-4gc7-5j7h-4qph)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Pivotal Spring Framework contains unsafe Java deserialization methods

(GHSA-4wrc-f8pq-fpqp)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Web vulnerable to Open Redirect or Server Side Request Forgery

(GHSA-ccgv-vj62-xf9h)


[CRITICAL] 1-1: org.springframework:spring-web 5.3.7: Spring Framework URL Parsing with Host Validation Vulnerability

(GHSA-hgjh-9rj2-g67j)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Remote Code Execution in Spring Framework

(GHSA-36p3-wjmg-h94x)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework is vulnerable to security bypass via mvcRequestMatcher pattern mismatch

(GHSA-7phw-cxx7-q9vq)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Path traversal vulnerability in functional web frameworks

(GHSA-cx7f-g6mp-7hqm)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework Path Traversal vulnerability

(GHSA-g5vr-rgqm-vf78)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring Framework MVC Applications Path Traversal Vulnerability

(GHSA-r936-gwx5-v52f)


[CRITICAL] 1-1: org.springframework:spring-webmvc 5.3.7: Spring MVC controller vulnerable to a DoS attack

(GHSA-w3c8-7r8f-9jp8)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Build tackle2-addon-analyzer
  • GitHub Check: Unit Tests (Phase 1)
🔇 Additional comments (27)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (3)

1-5: LGTM! Imports are appropriate for the JPA test fixture.

The package structure and imports are correctly organized for testing JPA variable binding.


7-15: Excellent documentation for the test fixture.

The Javadoc clearly explains the expected behavior for this test case, making it easy to understand the verification criteria.


16-19: LGTM! Standard JPA field injection pattern.

The class structure and EntityManager field declaration follow proper JPA conventions with the @PersistenceContext annotation.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1)

9-33: Class structure looks good for the intended inheritance/implements tests.

Abstract base + lifecycle methods + Serializable/Comparable wiring is straightforward and appropriate for the test-project scenarios.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1)

22-97: Overall structure matches the stated “search pattern” test goals.

Use of annotations, inheritance, constructors, collections, and java.io APIs is varied and should serve JDT.LS search/location testing well.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (3)

3-6: LGTM! Clean and minimal imports.

The imports are appropriate for a JMS Topic MessageDriven bean and all are utilized in the implementation.


18-21: LGTM! Clear implementation following established test pattern.

The onMessage implementation correctly logs the topic message with an appropriate prefix to differentiate it from queue-based messaging during test execution.


12-15: ****

The omission of acknowledgeMode is intentional and documented. TopicMessageProcessor's JavaDoc explicitly states the class tests "different attribute values" for Topic-based messaging, and the absence of acknowledgeMode is the deliberate variation being tested. This differs from MessageProcessor, which tests Queue configuration with the full set of properties. No changes are required.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1)

1-35: LGTM!

Comprehensive .gitignore with appropriate patterns for multiple IDEs, build tools, and operating systems. The patterns are standard and well-organized.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1)

7-9: LGTM!

Excluding DataSourceAutoConfiguration is the correct approach when using a custom PersistenceConfig with manual DataSource configuration, preventing conflicts between Spring Boot auto-configuration and custom bean definitions.

pom.xml (3)

26-26: LGTM!

Updating the coverage filter from org.eclipse.jdt.ls.* to io.konveyor.tackle.* correctly focuses code coverage on this project's packages rather than the underlying JDT.LS infrastructure.


73-73: LGTM!

Setting useUIHarness to false is appropriate for headless test execution in CI/CD environments and aligns with the automated integration test strategy introduced in this PR.


148-166: LGTM!

The Jacoco configuration correctly adds prepare-agent for coverage instrumentation and report execution bound to the verify phase. This is the standard setup for Maven-based code coverage reporting and aligns with the comprehensive test suite introduced in this PR.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1)

6-6: The original review comment is based on incorrect assumptions about the Spring Data version in use.

The project uses Spring Data 2021.0.1 (Spring Data 2.x), released May 14, 2021. In Spring Data 2.x, PagingAndSortingRepository correctly extends CrudRepository, making the interface declaration in CustomerRepository fully compatible and correct. The breaking change referenced in the review—where PagingAndSortingRepository no longer extends CrudRepository—only applies to Spring Data 3.0 and later (released November 18, 2022, after this project's version).

The code is valid as written and requires no changes.

Likely an incorrect or invalid review comment.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)

19-27: LGTM!

The custom exception implementation follows best practices: extends RuntimeException, declares serialVersionUID, and properly delegates to the superclass constructor.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (2)

1-232: Excellent test coverage for AnnotationQuery.

The test suite comprehensively covers constructor behavior, pattern matching (exact, regex, wildcard), fromMap factory method, elements handling, and location-based behavior across all location types.


180-191: Note: Non-defensive copy behavior is intentionally tested.

The test explicitly verifies that AnnotationQuery does not make a defensive copy of the elements map, meaning external mutations affect internal state. While this is intentional (per the comment), consider whether immutability would be safer for production use.

Makefile (1)

1-141: Well-structured CI/CD Makefile.

The Makefile provides a clean phase-based structure that mirrors the GitHub Actions workflow, with proper container runtime detection and SELinux-aware volume mounting for Podman.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1)

30-249: Comprehensive test expansion for command handler.

The test suite now covers a wide range of location types and analysis modes, providing thorough validation of the command handler's functionality across inheritance, method calls, constructors, annotations, imports, and more.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (1)

23-35: Good enhancement for type matching.

The addition of readable type conversion improves matching accuracy by allowing queries to match against both JVM signatures and human-readable type names (e.g., "I" and "int").

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (2)

122-156: Parameter matching logic looks solid and type‑erasure aware

The new parametersMatch(IMethodBinding) implementation correctly:

  • Treats “no parameters in query” as “match any parameter list”.
  • Compares counts and then each parameter type using getTypeName plus a wildcard‑aware regex.

Given you normalize generics via getErasure() and handle arrays/primitives in getTypeName, this should work well for common method/constructor overloads.

LGTM as a foundation for parameter‑sensitive symbol filtering.


161-175: Type-name normalization for primitives/arrays/generics is appropriate

getTypeName(ITypeBinding)’s handling of:

  • primitives (int, boolean),
  • arrays via recursive elementType + "[]", and
  • generic erasure (type.getErasure() then getQualifiedName())

is a good match for comparing against user‑supplied parameter type patterns (especially when combined with wildcard support).

No changes needed here.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (3)

163-207: SearchPattern extensions for erasure, packages, and enums look correct

The updates in getPatternSingleQuery:

  • Keep package searches (location 11) on R_PATTERN_MATCH, which aligns with JDT’s more flexible package matching.
  • Add R_ERASURE_MATCH for:
    • return/variable declaration type references (7, 9),
    • constructor calls (3),
    • field‑declaration type references (12),
      ensuring parameterized types like List<String> are found when searching for java.util.List.
  • Map enum_constant (6) to FIELD references, which is how enum constants are represented in JDT.

Combined with the existing switch and the location‑0 aggregation, this looks consistent and should improve matching of generics and enums without regressions.


248-321: Included-path handling and import-scan unit collection are consistent

The additions:

  • Use IPackageFragmentRoot.K_SOURCE to guard fragment.getCompilationUnits() when pre‑filling units.
  • Reuse the same units list later for the on‑demand import scan (location 8), further filtered by scope.encloses(unit).

This keeps binary packages out of the AST import scan while ensuring included fragments contribute all their compilation units. The logic remains bounded by the existing includedPaths and scope, so it should be safe performance‑wise.

LGTM.


342-355: Passing pattern into SymbolInformationTypeRequestor aligns with new matching behavior

The updated constructor call:

SymbolInformationTypeRequestor requestor =
    new SymbolInformationTypeRequestor(symbols, 0, monitor, location, query, annotationQuery, pattern);

properly propagates the final SearchPattern into the requestor, so downstream symbol providers (including your new ones) can leverage the more accurate pattern (erasure, package, enum handling, etc.).

No issues here.

java-analyzer-bundle.test/integration/client/jdtls_client.go (2)

167-216: Initialization flow and result handling look correct for test usage

The Initialize() method:

  • Builds a sensible InitializeParams struct (workspace URI, basic workspace/textDocument capabilities).
  • Sends initialize, waits for the InitializeResult, then sends initialized.
  • Sleeps briefly to give JDT.LS time to process projects.

For a test‑only client this is a reasonable balance between simplicity and correctness, assuming the hardcoded bundle path and workspace expectations are satisfied.


256-302: Symbol search command wiring and result unmarshalling look good

SearchSymbolsWithAnnotation:

  • Builds the expected io.konveyor.tackle.ruleEntry arguments map (project, query, location as string, analysisMode, optional includedPaths and annotationQuery).
  • Executes the command and defensively handles nil results.
  • Uses JSON round‑trip to convert any to []protocol.SymbolInformation, which is a pragmatic approach for loosely typed responses.

This should integrate cleanly with SampleDelegateCommandHandler.search(...).



public SymbolInformationTypeRequestor(List<SymbolInformation> symbols, int maxResults, IProgressMonitor monitor, int symbolKind, String query, AnnotationQuery annotationQuery) {
public SymbolInformationTypeRequestor(List<SymbolInformation> symbols, int maxResults, IProgressMonitor monitor, int symbolKind, String query, AnnotationQuery annotationQuery, SearchPattern searchPattern) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

Verify unused SearchPattern parameter.

The searchPattern parameter is added to the constructor but never stored or used. This suggests either incomplete implementation or unnecessary parameter passing.

Run the following script to check if this parameter will be used in the future or can be removed:


🏁 Script executed:

#!/bin/bash
# Check how SymbolInformationTypeRequestor is instantiated and if searchPattern is used elsewhere

# Find all instantiations of SymbolInformationTypeRequestor
rg -n "new SymbolInformationTypeRequestor" --type java -A 5

# Check if SearchPattern is used in symbol providers
rg -n "SearchPattern" --type java -g "**/*SymbolProvider.java" -C 3

Length of output: 1014



🏁 Script executed:

#!/bin/bash
# Inspect the SymbolInformationTypeRequestor class to verify if searchPattern is stored/used
ast-grep --pattern $'class SymbolInformationTypeRequestor {
  $$$
}'

Length of output: 0


🏁 Script executed:

#!/bin/bash
# More focused search: get the full class definition to check for searchPattern field
rg -nA 50 "class SymbolInformationTypeRequestor" --type java

Length of output: 7623



🏁 Script executed:

#!/bin/bash
# Check full SymbolInformationTypeRequestor class for any reference to searchPattern
rg -n "searchPattern" --type java java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java

Length of output: 213


Remove unused searchPattern parameter.

The searchPattern parameter added to the constructor at line 39 is never stored or used. No field is created for it, and it's not referenced anywhere in the class. This should be removed from the constructor signature and from the caller in SampleDelegateCommandHandler.java (line 354).

🤖 Prompt for AI Agents
In
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java
around line 39, the constructor includes an unused parameter searchPattern;
remove this parameter from the constructor signature and any constructor calls.
Also update the caller in SampleDelegateCommandHandler.java (around line 354) to
stop passing the searchPattern argument when instantiating
SymbolInformationTypeRequestor so constructor arguments match; ensure
imports/overloads remain consistent and compile.

Comment on lines +21 to +60
<dependencies>
<!-- Common dependencies for testing various patterns -->
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>

<!-- JPA/Persistence API for entity and persistence testing -->
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>javax.persistence-api</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>

<!-- EJB API for JMS and EJB annotations testing -->
<dependency>
<groupId>javax.ejb</groupId>
<artifactId>javax.ejb-api</artifactId>
<version>3.2.2</version>
<scope>provided</scope>
</dependency>

<!-- JMS API for message-driven bean testing -->
<dependency>
<groupId>javax.jms</groupId>
<artifactId>javax.jms-api</artifactId>
<version>2.0.1</version>
<scope>provided</scope>
</dependency>

<!-- Annotation API for @DataSourceDefinition -->
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.2</version>
<scope>provided</scope>
</dependency>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Review namespace consistency across Jakarta and Java EE dependencies.

The POM mixes jakarta.servlet-api 5.0.0 (Jakarta EE 9+ namespace) with javax.* APIs (Java EE 8 namespace). This inconsistency can lead to classpath conflicts or unexpected behavior:

  • Jakarta EE 9+: jakarta.servlet-api 5.0.0 (line 24-26)
  • Java EE 8: javax.persistence-api 2.2 (line 32), javax.ejb-api 3.2.2 (line 40), javax.jms-api 2.0.1 (line 48), javax.annotation-api 1.3.2 (line 56)

For consistency, either:

  1. Use Jakarta EE 9+ versions with jakarta.* namespace for all APIs (e.g., jakarta.persistence-api 3.0.0), or
  2. Use Java EE 8 versions with javax.* namespace for all APIs (e.g., javax.servlet-api 4.0.1)

If the intent is to test cross-version compatibility, please document this explicitly in the POM description or a comment.

Comment on lines +21 to +27
public void performJpaOperations() {
// Uses only JPA EntityManager, no JDBC
entityManager.persist(new Object());

Query query = entityManager.createQuery("SELECT u FROM User u");
query.getResultList();
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Replace new Object() with a proper JPA entity class.

Line 23 attempts to persist a plain Object instance, which will throw IllegalArgumentException at runtime since JPA requires entities to be annotated with @Entity. While this is a test fixture for static analysis, using proper JPA patterns ensures the code is valid and maintainable.

Consider one of these approaches:

Option 1: Create a simple entity class

Add a new entity class in the same package:

package io.konveyor.demo.persistence;

import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class TestEntity {
    @Id
    private Long id;
    
    public TestEntity() {}
}

Then update line 23:

-        entityManager.persist(new Object());
+        entityManager.persist(new TestEntity());

Option 2: Use null if execution isn't required

If the test only needs to be parsed but not executed:

-        entityManager.persist(new Object());
+        // Simplified for static analysis - would require proper @Entity in production
+        entityManager.persist(null);
🤖 Prompt for AI Agents
In
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java
around lines 21 to 27, line 23 is persisting a plain new Object() which will
throw at runtime because JPA requires an @Entity; replace that with a real JPA
entity instance (e.g., create a TestEntity class in the same package annotated
with @Entity and an @Id field, instantiate TestEntity and persist it), or if
execution is not required for the test, change the persist call to persist(null)
or remove the persist entirely so only valid JPA entities are used.

Comment on lines +103 to +104
$(CONTAINER_RUNTIME) run --rm \
-v $(REPO_ROOT)/java-analyzer-bundle.test:/tests$(VOLUME_FLAGS) \
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Verify volume mount path behavior across different invocation contexts.

The volume mount uses REPO_ROOT := $(shell pwd) which resolves at parse time. Ensure this works correctly if the Makefile is invoked from a different directory (e.g., make -C subdir target).

Run the following script to test the Makefile from different contexts:


🏁 Script executed:

#!/bin/bash
# Test Makefile invocation from different directories

# Test 1: From repo root
echo "Test 1: From repo root"
pwd
make -n run-integration-tests 2>&1 | grep "docker run" || echo "Failed"

# Test 2: From subdirectory
echo -e "\nTest 2: From subdirectory (if applicable)"
if [ -d "java-analyzer-bundle.test" ]; then
  cd java-analyzer-bundle.test
  pwd
  make -C .. -n run-integration-tests 2>&1 | grep "docker run" || echo "Failed"
fi

Length of output: 143


I need to investigate further. The "Failed" results indicate we need to see the actual Makefile output.


🏁 Script executed:

#!/bin/bash
# Check if Makefile exists and inspect the target and REPO_ROOT

echo "=== Check Makefile exists ==="
[ -f Makefile ] && echo "Makefile found at repo root" || echo "Makefile not found"

echo -e "\n=== Inspect run-integration-tests target and lines 103-104 ==="
if [ -f Makefile ]; then
  sed -n '95,115p' Makefile
fi

echo -e "\n=== Test 1: make -n run-integration-tests (raw output, no grep) ==="
make -n run-integration-tests 2>&1 | head -20

echo -e "\n=== Test 2: Check REPO_ROOT from repo root ==="
make -n -e 'run-integration-tests' 2>&1 | grep -i "REPO_ROOT\|repo_root" | head -5

echo -e "\n=== Test 3: From subdirectory - check REPO_ROOT ==="
if [ -d "java-analyzer-bundle.test" ]; then
  cd java-analyzer-bundle.test
  echo "Current dir: $(pwd)"
  make -C .. -n run-integration-tests 2>&1 | grep -i "REPO_ROOT\|repo_root" | head -5
fi

Length of output: 1100


I need to inspect the Makefile to find where REPO_ROOT is defined.


🏁 Script executed:

#!/bin/bash
# Find REPO_ROOT definition and understand its context

echo "=== Search for REPO_ROOT definition in Makefile ==="
grep -n "REPO_ROOT" Makefile | head -20

echo -e "\n=== Show first 50 lines of Makefile to see variable definitions ==="
head -50 Makefile

echo -e "\n=== Show lines around first REPO_ROOT reference ==="
grep -n "REPO_ROOT" Makefile | head -1 | cut -d: -f1 | xargs -I {} sed -n '{}p;$(({}+5))p;$(({}+10))p' Makefile

Length of output: 2208


Replace $(shell pwd) with path-relative variable for robust Makefile portability.

The current definition at line 21 (REPO_ROOT := $(shell pwd)) is not portable across different invocation contexts. While it works when invoked from the repo root or with -C flag, it relies on the working directory at parse time and can fail if the Makefile is sourced or invoked from unexpected locations.

Replace with:

REPO_ROOT := $(dir $(abspath $(lastword $(MAKEFILE_LIST))))

This resolves to the Makefile's actual directory regardless of where make is invoked from, ensuring correct volume mount paths in line 104 across all contexts.

🤖 Prompt for AI Agents
In Makefile around lines 103–104, the REPO_ROOT usage for the volume mount is
fragile because REPO_ROOT is currently set at line 21 using $(shell pwd);
replace that assignment so REPO_ROOT is computed from the Makefile location
itself by using a construct that combines dir, abspath and lastword on
MAKEFILE_LIST (i.e., compute the directory of the current Makefile rather than
calling pwd) so the volume mount path is correct regardless of where make is
invoked.

@shawn-hurley shawn-hurley force-pushed the testing/adding-bundle-specific-tests branch from c5cc10c to 62d4fd2 Compare November 18, 2025 21:36
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

♻️ Duplicate comments (21)
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1)

238-249: Test expects incorrect exception type—will fail at runtime.

This is the same critical issue previously identified: when the "location" key is missing, obj.get("location") returns null, and Integer.parseInt((String) null) throws NullPointerException, not NumberFormatException.

The test must expect NullPointerException, or better yet, the RuleEntryParams implementation should be fixed to explicitly check for null and throw a descriptive IllegalArgumentException (e.g., "location parameter is required") before attempting to parse.

Apply this diff to temporarily fix the test to match current behavior:

-	@Test(expected = NumberFormatException.class)
+	@Test(expected = NullPointerException.class)
 	public void testMissingLocation() {

However, the recommended long-term fix is to update RuleEntryParams to validate the presence of "location" before parsing, then update this test to expect IllegalArgumentException.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (1)

107-108: Still using incorrect location in fallback path.

This is the same issue flagged in the previous review. Line 107 still uses getLocation(element, match), which anchors every symbol to the type-reference match position instead of the actual variable identifier. The VariableInfo captures the correct offset and length for each variable name (lines 89-90), but these values are never used.

To fix this, you need to construct the location from varInfo.offset and varInfo.length using the compilation unit. Here's the corrected approach:

                // Create location for the variable name
-                symbol.setLocation(getLocation(element, match));
+                org.eclipse.lsp4j.Location location = new org.eclipse.lsp4j.Location();
+                location.setUri(unit.getResource().getLocationURI().toString());
+                org.eclipse.lsp4j.Range range = new org.eclipse.lsp4j.Range();
+                int startLine = cu.getLineNumber(varInfo.offset) - 1;
+                int startCol = cu.getColumnNumber(varInfo.offset);
+                int endLine = cu.getLineNumber(varInfo.offset + varInfo.length) - 1;
+                int endCol = cu.getColumnNumber(varInfo.offset + varInfo.length);
+                range.setStart(new org.eclipse.lsp4j.Position(startLine, startCol));
+                range.setEnd(new org.eclipse.lsp4j.Position(endLine, endCol));
+                location.setRange(range);
+                symbol.setLocation(location);

Without this fix, "go to definition" will incorrectly navigate to the type token rather than the variable name.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2)

34-46: Use consistent project name "test-project" across test suite.

Line 38 uses "project" while all other tests (15+) use "test-project". This inconsistency was flagged in a previous review but remains unresolved. Update to "test-project" for consistency with test infrastructure.

Apply this diff:

-		Map<String, String> param = Map.of(
-			"project", "project",
+		Map<String, String> param = Map.of(
+			"project", "test-project",

236-249: Replace "TestClass" with an existing test class.

Line 241 queries for "TestClass" which doesn't exist in test-project (as flagged in previous review). This test will always return empty results and fails to validate class_declaration location handling. Update to an existing class like "SampleApplication", "Calculator", or "EnumExample" from io.konveyor.demo.

Apply this diff to use an existing class:

 		Map<String, String> param = Map.of(
 			"project", "test-project",
-			"query", "TestClass",
+			"query", "SampleApplication",
 			"location", "14",  // class_declaration
 			"analysisMode", "source-only"
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (3)

40-43: Document intent if incomplete initialization is deliberate.

The parameterized constructor leaves configFile uninitialized, which can cause NullPointerException when writeToFile() or fileOperations() is called. This issue was previously flagged. If this incomplete initialization is intentional for testing error scenarios, please add a comment documenting the intent. Otherwise, initialize configFile to a default value.


66-71: Resource leak remains unaddressed.

The FileWriter is not properly closed if write() throws an exception, causing a resource leak. This issue was previously flagged. Use try-with-resources to ensure proper cleanup:

-public void writeToFile(String data) throws IOException {
-    // Constructor call with chained method call
-    FileWriter writer = new FileWriter(configFile);
-    writer.write(data);
-    writer.close();
-}
+public void writeToFile(String data) throws IOException {
+    // Constructor call with chained method call
+    try (FileWriter writer = new FileWriter(configFile)) {
+        writer.write(data);
+    }
+}

If this resource leak is intentional for testing error scenarios, please add a comment documenting the intent.


79-91: Inverted directory existence logic remains unaddressed.

The directory existence check at lines 85-87 is backwards: the code calls dir.mkdirs() only when the directory EXISTS, not when it doesn't exist. This issue was previously flagged:

-if (dir.exists()) {
+if (!dir.exists()) {
     dir.mkdirs();
 }

If this inverted logic is intentional for testing error scenarios, please add a comment documenting the intent.

java-analyzer-bundle.test/docs/quick-reference.md (1)

338-340: Fix broken documentation reference.

The link to QUERY_COVERAGE.md appears to be incorrect. Based on the past review comment, this should reference docs/query-reference.md instead. Please verify the correct path and update the link accordingly.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (2)

25-33: Fix the path mapping to include path variable template.

The @GetMapping value is missing the template variable syntax, preventing @PathVariable("id") from binding correctly. This will cause the endpoint to fail at runtime.

Apply this diff:

-	@GetMapping(value = "id", produces = MediaType.APPLICATION_JSON_VALUE)
+	@GetMapping(value = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE)

29-29: Correct the error message to refer to "customer" instead of "order".

The error message references "order" but this endpoint handles customer resources.

Apply this diff:

-		throw new ResourceNotFoundException("Requested order doesn't exist");
+		throw new ResourceNotFoundException("Requested customer doesn't exist");
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (3)

41-51: Inject ApplicationConfiguration instead of creating new instances.

Creating a new ApplicationConfiguration instance inside the @Bean method bypasses Spring's dependency injection and could lead to inconsistent configuration.

Apply constructor injection:

+	private final ApplicationConfiguration config;
+	
+	public PersistenceConfig(ApplicationConfiguration config) {
+		this.config = config;
+	}
+	
 	@Bean
 	public DataSource dataSource() {
-		ApplicationConfiguration config = new ApplicationConfiguration();
 		final DriverManagerDataSource dataSource = new DriverManagerDataSource();

53-58: Inject EntityManagerFactory instead of calling the bean method directly.

Calling entityManagerFactory().getObject() directly bypasses Spring-managed bean injection and can cause lifecycle issues.

Apply this diff:

 	@Bean
-	public PlatformTransactionManager transactionManager() {
+	public PlatformTransactionManager transactionManager(LocalContainerEntityManagerFactoryBean entityManagerFactory) {
 		final JpaTransactionManager transactionManager = new JpaTransactionManager();
-		transactionManager.setEntityManagerFactory(entityManagerFactory().getObject());
+		transactionManager.setEntityManagerFactory(entityManagerFactory.getObject());
 		return transactionManager;
 	}

65-73: Use injected ApplicationConfiguration in helper method.

This method creates another new ApplicationConfiguration instance instead of using the injected dependency.

After applying constructor injection from the previous comment:

 	final Properties additionalProperties() {
-		ApplicationConfiguration config = new ApplicationConfiguration();
 		final Properties hibernateProperties = new Properties();
java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (3)

19-19: Update Spring Framework to address critical vulnerabilities.

Spring Web/WebMVC 5.3.7 has multiple critical vulnerabilities including DoS, path traversal, and RCE. Even in test projects, vulnerable dependencies create supply chain risks.

Apply this diff:

-		<spring-framework.version>5.3.7</spring-framework.version>
+		<spring-framework.version>5.3.39</spring-framework.version>

117-119: Update logback-classic to address critical vulnerabilities.

Version 1.1.7 has multiple critical deserialization vulnerabilities. Even for test projects, using vulnerable dependencies creates supply chain risks.

Apply this diff:

 		<dependency>
 			<groupId>ch.qos.logback</groupId>
 			<artifactId>logback-classic</artifactId>
-			<version>1.1.7</version>
+			<version>1.3.14</version>
 		</dependency>

127-129: Update PostgreSQL driver to address critical vulnerabilities.

Version 42.2.23 has multiple critical vulnerabilities including SQL injection, arbitrary file write, and path traversal.

Apply this diff:

 		<dependency>
 			<groupId>org.postgresql</groupId>
 			<artifactId>postgresql</artifactId>
-			<version>42.2.23</version>
+			<version>42.7.4</version>
 		</dependency>
Makefile (1)

19-23: Make REPO_ROOT independent of the caller’s working directory.

REPO_ROOT := $(shell pwd) works only when make is invoked from the repo root. With make -C or other entry points, the volume mount in run-integration-tests can point at the wrong path.

Derive REPO_ROOT from the Makefile’s location instead:

-REPO_ROOT := $(shell pwd)
+REPO_ROOT := $(dir $(abspath $(lastword $(MAKEFILE_LIST))))

This keeps the mount stable regardless of where make is run from.

Also applies to: 103-110

java-analyzer-bundle.test/integration/client/jdtls_client.go (3)

32-37: Simplify CmdDialer: remove unused err field and guards.

CmdDialer.err is never set, so the checks in Read, Write, and Dial never trigger. This adds complexity without value.

You can simplify:

-type CmdDialer struct {
-	Cmd    *exec.Cmd
-	Stdin  io.WriteCloser
-	Stdout io.ReadCloser
-	err    error
-}
+type CmdDialer struct {
+	Cmd    *exec.Cmd
+	Stdin  io.WriteCloser
+	Stdout io.ReadCloser
+}
@@
 func (rwc *CmdDialer) Read(p []byte) (int, error) {
-	if rwc.err != nil {
-		return 0, fmt.Errorf("cannot read: %w", rwc.err)
-	}
 	return rwc.Stdout.Read(p)
 }
@@
 func (rwc *CmdDialer) Write(p []byte) (int, error) {
-	if rwc.err != nil {
-		return 0, fmt.Errorf("cannot write: %w", rwc.err)
-	}
 	return rwc.Stdin.Write(p)
 }
@@
 func (rwc *CmdDialer) Dial(ctx context.Context) (io.ReadWriteCloser, error) {
-	if rwc.err != nil {
-		return rwc, fmt.Errorf("cannot dial: %w", rwc.err)
-	}
 	return rwc, nil
 }

Also applies to: 39-50, 65-68


107-115: Make configDir selection OS-aware instead of hardcoding config_linux.

Right now the JDT.LS config directory is always <jdtlsPath>/config_linux, which breaks if these tests are ever run on macOS/Windows or with a different JDT.LS layout.

Consider deriving the suffix from runtime.GOOS and adding the import:

+import "runtime"
@@
-	configDir := filepath.Join(c.jdtlsPath, "config_linux")
+	var cfgSuffix string
+	switch runtime.GOOS {
+	case "darwin":
+		cfgSuffix = "config_mac"
+	case "windows":
+		cfgSuffix = "config_win"
+	default:
+		cfgSuffix = "config_linux"
+	}
+	configDir := filepath.Join(c.jdtlsPath, cfgSuffix)

Please double‑check the actual directory names in the JDT.LS distribution you’re using and adjust the suffixes accordingly.


304-359: Harden Shutdown against nil conn / partially started processes.

Shutdown assumes c.conn, c.cancel, and c.cmd are always non‑nil. If a future caller invokes Shutdown/Close after a failed Start (or before Start), this will panic.

Add a fast path that cleans up what exists without dereferencing nils, e.g.:

 func (c *JDTLSClient) Shutdown() error {
 	c.logger.Info("Shutting down JDT.LS server...")
 
+	// If no connection was ever established, just tear down process/dialer/cancel.
+	if c.conn == nil {
+		if c.cancel != nil {
+			c.cancel()
+		}
+		if c.dialer != nil {
+			_ = c.dialer.Close()
+		}
+		if c.cmd != nil && c.cmd.Process != nil {
+			_ = c.cmd.Process.Kill()
+			_ = c.cmd.Wait()
+		}
+		return nil
+	}
+
 	// Create a context with timeout for shutdown requests
 	shutdownCtx, shutdownCancel := context.WithTimeout(c.ctx, 3*time.Second)

This keeps the client safe if its lifecycle is used differently in the future.

java-analyzer-bundle.test/integration/integration_test.go (1)

100-145: Fix inheritance test expectations and the exceptedFileName typo.

The table-driven inheritance tests have two issues:

  1. The "Find DataService extends BaseService" case still expects "SampleApplication", so it will not fail if DataService is missing.
  2. The field name exceptedFileName is a typo and the error message is hardcoded to SampleApplication.

Consider:

-   exceptedFileName string
+   expectedFileName string
@@
-        Name:             "Find DataService extends BaseService",
+        Name:             "Find DataService extends BaseService",
         projectName:      "test-project",
         query:            "io.konveyor.demo.inheritance.BaseService",
         location:         1,
         analysisMode:     "source-only",
-        exceptedFileName: "SampleApplication",
+        expectedFileName: "DataService",
@@
-   if !verifySymbolInResults(symbols, tc.exceptedFileName) {
-       t.Errorf("SampleApplication not found in results")
+   if !verifySymbolInResults(symbols, tc.expectedFileName) {
+       t.Errorf("%s not found in results", tc.expectedFileName)
    }

Apply the expectedFileName rename consistently across all test cases and usages.

🧹 Nitpick comments (12)
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (2)

55-60: Remove unused element discovery code.

The element variable is assigned but never used beyond logging at line 57. This appears to be leftover debug code that should be removed to avoid unnecessary computation and improve code clarity.

Additionally, line 57 has a typo: "je" should be "je: " for consistency with other log statements.

Apply this diff to remove the unused code:

-            IJavaElement element = JDTUtils.findElementAtSelection(mod.getTypeRoot(), location.getRange().getStart().getLine(), location.getRange().getStart().getCharacter(), JavaLanguageServerPlugin.getPreferencesManager(), new NullProgressMonitor());
-
-            logInfo("je" + element);
-
-
-            

And remove the now-unused imports at the top of the file:

-import org.eclipse.core.runtime.NullProgressMonitor;
 import org.eclipse.jdt.core.IClassFile;
 import org.eclipse.jdt.core.ICompilationUnit;
 import org.eclipse.jdt.core.IJavaElement;
 import org.eclipse.jdt.core.IMethod;
 import org.eclipse.jdt.core.dom.AST;
 import org.eclipse.jdt.core.dom.ASTParser;
 import org.eclipse.jdt.core.dom.CompilationUnit;
 import org.eclipse.jdt.core.search.MethodReferenceMatch;
 import org.eclipse.jdt.core.search.SearchMatch;
 import org.eclipse.jdt.internal.core.JavaElement;
-import org.eclipse.jdt.ls.core.internal.JDTUtils;
-import org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin;

69-78: Consider improving code formatting and comment placement.

The indentation at line 75 appears inconsistent with the surrounding code block, and the comment at line 74 is oddly placed right before cu.accept(visitor) rather than near the binding resolution logic it references.

Consider reformatting for better readability:

                 ASTParser astParser = ASTParser.newParser(AST.getJLSLatest());
                 astParser.setSource(unit);
                 astParser.setResolveBindings(true);
                 CompilationUnit cu = (CompilationUnit) astParser.createAST(null);
                 CustomASTVisitor visitor = new CustomASTVisitor(query, match, QueryLocation.CONSTRUCTOR_CALL);
-                // Under tests, resolveConstructorBinding will return null if there are problems
-                    cu.accept(visitor);
-                    if (visitor.symbolMatches()) {
-                        symbols.add(symbol);
-                    }
+                // Under tests, resolveConstructorBinding will return null if there are problems
+                cu.accept(visitor);
+                if (visitor.symbolMatches()) {
+                    symbols.add(symbol);
+                }
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1)

18-21: LGTM! The implementation appropriately serves its test purpose.

The onMessage method correctly implements the MessageListener interface with a simple console output for verification. This is suitable for integration testing where the goal is to verify that the analyzer correctly detects JMS Topic configurations.

Optional: Consider using a proper logger instead of System.out to align with best practices, even in test code:

+import java.util.logging.Logger;
+
 public class TopicMessageProcessor implements MessageListener {
+    private static final Logger LOGGER = Logger.getLogger(TopicMessageProcessor.class.getName());

     @Override
     public void onMessage(Message message) {
-        System.out.println("Processing topic message: " + message);
+        LOGGER.info("Processing topic message: " + message);
     }
 }
java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (2)

37-77: Pattern matching tests are comprehensive.

The tests cover exact matching, regex patterns, wildcards, and null type scenarios effectively.

Consider adding a test for invalid regex patterns to ensure graceful error handling:

@Test(expected = PatternSyntaxException.class)
public void testMatchesAnnotationInvalidPattern() {
    AnnotationQuery query = new AnnotationQuery("[invalid(regex", new HashMap<>(), false);
    query.matchesAnnotation("javax.ejb.Stateless");
}

79-157: fromMap tests are correct but use magic numbers for location types.

The tests correctly verify the factory method behavior across different scenarios. However, the hardcoded location values (4 for annotation location, 10 for type location) reduce maintainability.

Consider extracting location type constants to improve maintainability and self-documentation:

private static final int LOCATION_ANNOTATION = 4;
private static final int LOCATION_TYPE = 10;

// Then use in tests:
AnnotationQuery query = AnnotationQuery.fromMap("fallbackQuery", annotationQueryMap, LOCATION_ANNOTATION);

Alternatively, if these constants exist in the production code (e.g., in a LocationType class or enum), import and use them directly.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (1)

80-81: Consider tightening the overlap condition.

The current logic matches if matchOffset falls anywhere within the type node range. While functional, it might match unintended statements if there are nested type references or complex expressions. Consider checking both start and end boundaries:

-                    if (typeStart == matchOffset ||
-                        (matchOffset >= typeStart && matchOffset < typeStart + typeLength)) {
+                    if (matchOffset >= typeStart && 
+                        matchOffset + matchLength <= typeStart + typeLength) {

This ensures the entire match range is contained within the type node.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (2)

48-61: Document the location code for clarity.

Location code "10" (line 54) is not documented with an inline comment, unlike most other tests. Add a comment (e.g., // type) to clarify what this location type represents for better test maintainability.


176-189: Document location code and note similarity to testRuleEntryWithFullMode.

This test is very similar to testRuleEntryWithFullMode (lines 48-61): both query "java.io.*" with location "10", differing only in analysisMode. Consider:

  1. Adding a comment on line 182 to document what location "10" represents (appears to be a type/class location).
  2. Clarifying via test name or comments that this test specifically validates source-only mode behavior with wildcard queries.
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java (1)

19-30: Consider try-with-resources for more robust resource management.

While explicit close() calls are present, an exception occurring between resource creation and the close statements would cause a leak. Try-with-resources ensures cleanup even when exceptions occur.

Apply this diff to use try-with-resources:

     public void executeQuery(Connection conn) throws SQLException {
         // Uses only JDBC PreparedStatement
-        PreparedStatement stmt = conn.prepareStatement("SELECT * FROM products");
-        ResultSet rs = stmt.executeQuery();
-
-        while (rs.next()) {
-            System.out.println("Product: " + rs.getString("name"));
+        try (PreparedStatement stmt = conn.prepareStatement("SELECT * FROM products");
+             ResultSet rs = stmt.executeQuery()) {
+            
+            while (rs.next()) {
+                System.out.println("Product: " + rs.getString("name"));
+            }
         }
-
-        rs.close();
-        stmt.close();
     }
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1)

28-42: Consider logging unexpected element types for debugging.

When the element is not a FIELD type (line 29), the method silently returns an empty list. While this might be intentional, adding a debug log statement would help troubleshoot cases where enum constant searches unexpectedly return no results.

Apply this diff to add optional debug logging:

             // Enum constants are fields, so we need to check if the element is a field
             if (element.getElementType() == IJavaElement.FIELD) {
                 IField field = (IField) element;
 
                 // Only include if it's actually an enum constant
                 if (field.isEnumConstant()) {
                     SymbolInformation symbol = new SymbolInformation();
                     symbol.setName(field.getElementName());
                     symbol.setKind(convertSymbolKind(field));
                     symbol.setContainerName(field.getParent().getElementName());
                     symbol.setLocation(getLocation(field, match));
                     symbols.add(symbol);
                 }
+            } else {
+                logInfo("EnumConstantSymbolProvider: element is not a FIELD, type=" + element.getElementType());
             }
java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1)

72-74: Use structured logging instead of printStackTrace().

The exception handler uses printStackTrace() which outputs to stderr. For consistency with the rest of the codebase, use structured logging.

Apply this diff:

 	} catch (Exception e) {
 		logInfo("Error processing package declaration: " + e.toString());
-		e.printStackTrace();
+		logInfo("Stack trace: " + java.util.Arrays.toString(e.getStackTrace()));
 	}
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1)

13-34: Service behavior is fine; a couple of optional style tweaks.

The implementation correctly delegates to CustomerRepository and adds useful debug logging. If you want to align more with typical Spring style later:

  • Prefer constructor injection over field @Autowired to ease testing.
  • Make the logger a private static final with an upper‑case name:
private static final Logger LOGGER = Logger.getLogger(CustomerService.class);

These are non-blocking; the current code is acceptable for this test project.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 874b097 and 62d4fd2.

⛔ Files ignored due to path filters (1)
  • java-analyzer-bundle.test/integration/go.sum is excluded by !**/*.sum
📒 Files selected for processing (71)
  • .github/workflows/integration-tests.yml (1 hunks)
  • .gitignore (1 hunks)
  • Dockerfile (2 hunks)
  • Dockerfile.test (1 hunks)
  • Makefile (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (6 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java (2 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ConstructorCallSymbolProvider.java (3 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java (4 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (2 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java (1 hunks)
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (1 hunks)
  • java-analyzer-bundle.test/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/README.md (1 hunks)
  • java-analyzer-bundle.test/docs/integration-tests.md (1 hunks)
  • java-analyzer-bundle.test/docs/query-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/quick-reference.md (1 hunks)
  • java-analyzer-bundle.test/docs/test-projects.md (1 hunks)
  • java-analyzer-bundle.test/integration/client/jdtls_client.go (1 hunks)
  • java-analyzer-bundle.test/integration/go.mod (1 hunks)
  • java-analyzer-bundle.test/integration/integration_test.go (1 hunks)
  • java-analyzer-bundle.test/integration/run_local.sh (1 hunks)
  • java-analyzer-bundle.test/integration/test_helpers.go (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/PersistenceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/controller/CustomerController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/CustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql (1 hunks)
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties (1 hunks)
  • java-analyzer-bundle.test/projects/maven/springboot-todo/.project (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.classpath (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.project (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/pom.xml (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/JdbcOnlyService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (1 hunks)
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/ServiceWithEntityManager.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (1 hunks)
  • java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (1 hunks)
  • pom.xml (4 hunks)
✅ Files skipped from review due to trivial changes (2)
  • java-analyzer-bundle.test/docs/query-reference.md
  • java-analyzer-bundle.test/README.md
🚧 Files skipped from review as they are similar to previous changes (30)
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.apt.core.prefs
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/OrderManagementAppInitializer.java
  • java-analyzer-bundle.test/integration/go.mod
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/config/WebConfig.java
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.m2e.core.prefs
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/service/ICustomerService.java
  • java-analyzer-bundle.test/projects/test-project/pom.xml
  • java-analyzer-bundle.test/integration/test_helpers.go
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/Makefile
  • java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.core.resources.prefs
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/.gitignore
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/import.sql
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/MessageProcessor.java
  • pom.xml
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/CustomASTVisitor.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/DataSourceConfig.java
  • java-analyzer-bundle.test/integration/run_local.sh
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/entity/Product.java
  • .gitignore
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/config/MySQLDataSourceConfig.java
  • java-analyzer-bundle.test/docs/test-projects.md
  • java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SymbolInformationTypeRequestor.java
  • java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/handler/ExceptionHandlingController.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/DataService.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/EnumExample.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/ServletExample.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/BaseService.java
  • java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/DeprecatedApi.java
  • .github/workflows/integration-tests.yml
  • java-analyzer-bundle.test/projects/test-project/.classpath
🔇 Additional comments (63)
java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/inheritance/CustomException.java (1)

1-21: Custom exception implementation looks correct and idiomatic

The class cleanly follows the standard pattern for a checked custom exception (package, serialVersionUID, and three common constructors delegating to super). This is appropriate for its role as a test fixture for inheritance behavior. No changes needed.

java-analyzer-bundle.test/projects/maven/springboot-todo/.project (1)

23-33: LGTM! Standard Eclipse resource filtering configuration.

The filteredResources section appropriately excludes common directories and files from the Eclipse project explorer (node_modules, .git, and JDT.LS marker files). This is a standard configuration for Java development environments.

java-analyzer-bundle.test/projects/test-project/.project (1)

1-34: LGTM! Well-structured Eclipse project configuration.

The project descriptor is correctly configured with appropriate build specifications, natures, and resource filtering. The filteredResources section uses the same pattern as the springboot-todo project, maintaining consistency across the test suite while using a unique filter ID.

java-analyzer-bundle.test/docs/README.md (2)

7-7: Verify that all cross-referenced documentation files and relative paths are present and correctly positioned.

The README references four related documentation files (quick-reference.md, query-reference.md, integration-tests.md, test-projects.md) and two external resources via relative paths (../../README.md, ../../CLAUDE.md). Confirm these files exist in the PR and that the relative paths resolve correctly from the docs folder context.

Also applies to: 22-22, 37-37, 53-53, 305-306


128-138: Verify test counts and Phase 1/Phase 2 test structure match actual test implementations.

The documentation specifies 48 tests in Phase 1 (Maven unit tests) and 16 functions in Phase 2 (Go integration tests). Confirm these counts are accurate by cross-referencing with the actual test files and ensure the test names listed (RuleEntryParamsTest, AnnotationQueryTest, SampleDelegateCommandHandlerTest for Phase 1; and the 16 TestXxx functions for Phase 2) correspond to the actual test implementations.

Also applies to: 142-166

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/jms/TopicMessageProcessor.java (4)

1-6: LGTM!

The package declaration and imports are appropriate for a JMS message-driven bean test class. All necessary JEE and JMS types are correctly imported.


8-11: LGTM!

The Javadoc clearly documents the test purpose, making it easy to understand that this class is designed to test JMS Topic configuration detection.


12-15: LGTM!

The @MessageDriven annotation is correctly configured for JMS Topic message processing. The activation config properties properly specify a Topic destination type and lookup name.


16-16: LGTM!

The class declaration correctly implements MessageListener, which is the required interface for message-driven beans.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/Calculator.java (7)

1-8: LGTM! Clear test fixture structure.

The package structure, import, and class documentation are well-organized. The Javadoc clearly states the testing purpose (location type 7 coverage and method declarations), which helps maintainability of the integration test suite.


10-13: LGTM! Simple and effective test method.

The add method correctly demonstrates integer return types for the analyzer test coverage.


15-21: LGTM! Appropriate error handling for test fixture.

The divide method correctly demonstrates double return types and includes proper division-by-zero checking. The b == 0 comparison is acceptable for checking against the literal zero value.


23-26: LGTM! Clean string formatting method.

The format method appropriately tests String return types for the integration test coverage.


28-31: LGTM! Tests custom return types effectively.

The getStatus method demonstrates the analyzer's capability to handle custom enum return types.


33-37: LGTM! Intentional deprecation for annotation testing.

The sum method is correctly annotated with the custom @DeprecatedApi annotation, allowing the integration tests to verify the analyzer's handling of deprecated methods and custom annotations.


39-42: LGTM! Appropriate void method for testing.

The reset method correctly demonstrates void return types. The console output is acceptable for a test fixture and may serve test verification purposes.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/RuleEntryParamsTest.java (5)

19-51: LGTM! Basic parameter parsing tests are well-structured.

The tests correctly validate parsing of project name, query, location, and analysis modes (both "full" and "source-only"). The assertions are appropriate and the test data is representative.


53-154: LGTM! Configuration parameter tests provide excellent coverage.

The tests comprehensively validate included paths, open-source libraries flag (including default behavior), and Maven repository paths. The explicit test for the default value of includeOpenSourceLibraries (lines 108-122) is particularly good practice.


156-173: LGTM! Comprehensive location type coverage.

Excellent use of a parameterized approach to validate all 15 location types (0-14). This ensures complete coverage and makes it easy to maintain if location types are added or modified.


175-216: LGTM! Annotation query tests handle both present and absent scenarios.

The tests properly validate complex nested parameter structures (lines 184-194) and correctly assert null when the optional annotationQuery parameter is omitted. Good coverage of optional parameter handling.


218-236: LGTM! Error condition tests correctly validate exception handling.

The test for missing arguments (lines 218-223) appropriately expects UnsupportedOperationException, and the invalid location format test (lines 225-236) correctly expects NumberFormatException when parsing a non-numeric string.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/query/AnnotationQueryTest.java (3)

18-35: LGTM! Basic constructor and getter tests are well-structured.

The tests correctly verify the constructor parameters and getter methods with clear assertions.


179-191: Verify that mutable shared state is the intended design.

The test explicitly verifies that the AnnotationQuery does not perform a defensive copy of the elements map, meaning external modifications affect the query's internal state. This violates encapsulation and can lead to unexpected behavior.

Please confirm this is the intended design. If not, consider implementing defensive copying:

// In AnnotationQuery constructor:
this.elements = new HashMap<>(elements);

// And update the test expectation:
assertEquals("original", query.getElements().get("value"));

If this behavior is intentional (e.g., for performance reasons), consider documenting this in the production class and making the elements map unmodifiable via Collections.unmodifiableMap() to prevent accidental modifications while still avoiding the copy overhead.


193-231: LGTM! Additional test coverage is thorough.

The tests effectively cover complex regex patterns, empty collections, and behavior across multiple location types. The testFromMapMultipleLocations is particularly valuable for verifying that only location 4 triggers annotation-specific behavior.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/VariableDeclarationSymbolProvider.java (3)

32-34: LGTM! Type guard is appropriate.

The early type check prevents processing incompatible match types and ensures type safety for the cast on line 36.


39-48: LGTM! Fast path handles standard cases correctly.

When getLocalElement() succeeds, this path correctly constructs the symbol from the ILocalVariable with proper name, kind, container, and location.


64-67: AST parsing approach is appropriate for the fallback case.

Disabling binding resolution (line 66) is a good optimization since only structural information is needed. Parsing the entire compilation unit does have performance implications, but this is acceptable given it's a fallback path for interface types where getLocalElement() fails.

java-analyzer-bundle.test/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandlerTest.java (6)

1-14: LGTM!

The imports are appropriate and cover all necessary testing utilities, assertions, and collection types used throughout the test file.


16-27: LGTM!

The class setup and initialization are clean. The "Integration test" label in the javadoc aligns with the PR's objective of adding comprehensive integration test coverage.


29-32: LGTM!

The basic command test correctly verifies the simple "Hello World" response from the base command handler.


122-174: LGTM!

These tests appropriately cover implements_type, import, includedPaths parameter handling, and exception behavior for unsupported commands. The use of HashMap in testRuleEntryWithIncludedPaths correctly accommodates the ArrayList parameter type.


191-234: LGTM!

These tests appropriately cover package, field, and method declaration location types with well-documented location codes.


93-105: Verify javax.ejb.Stateless annotation exists in test-project.

This test searches for javax.ejb.Stateless (line 98). Ensure this annotation exists in the test-project classes, otherwise the test will always return empty results and won't effectively validate annotation location handling.

Run the following script to verify the annotation exists:

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/ServiceWithEntityManager.java (1)

1-29: Test fixture serves its purpose for analyzer detection.

This test class appropriately demonstrates mixed JPA/JDBC usage patterns for exercising the analyzer's symbol search and file filtering capabilities, as documented in the javadoc.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/PureJpaService.java (1)

1-28: Test fixture appropriately demonstrates pure JPA usage pattern.

This class correctly serves its documented purpose of providing test data containing only EntityManager usage without PreparedStatement, enabling verification of the analyzer's filtering capabilities.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/persistence/AnotherMixedService.java (1)

1-27: Test fixture provides additional mixed usage scenario for analyzer testing.

This class complements ServiceWithEntityManager by providing a second example of mixed JPA/JDBC usage, enhancing test coverage for the analyzer's file filtering and symbol search capabilities.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/annotations/CustomAnnotation.java (1)

1-17: LGTM! Well-structured test annotation.

The annotation definition is correct and appropriate for testing. Runtime retention enables reflection-based searches, and the target types (TYPE, METHOD, FIELD) provide comprehensive coverage for annotation search pattern testing.

java-analyzer-bundle.test/projects/test-project/src/main/java/io/konveyor/demo/SampleApplication.java (6)

1-23: LGTM! Clear test fixture structure.

The class declaration, imports, and annotation usage are correct. The JavaDoc effectively documents the testing purpose and coverage of different JDT.LS location types.


25-31: Field declarations are correct.

The field declarations appropriately demonstrate various types for testing field declaration searches.


33-38: Constructor patterns appear intentional for testing.

The default constructor correctly initializes all fields. The use of new String("Test Application") (line 35) and explicit type parameters (line 36) appear to be intentional test patterns to verify constructor call detection, as indicated by the comments.


46-63: LGTM! Methods demonstrate test patterns correctly.

The processData() and getName() methods correctly demonstrate various patterns for testing (variable declarations, method calls, constructor calls, type references).


73-76: LGTM! Static method is correct.

The static method correctly demonstrates a simple static method pattern for testing.


93-96: LGTM! Override implementation is correct.

The initialize() method correctly overrides the base class method with an appropriate test implementation.

Dockerfile (2)

25-26: LGTM! Clean environment variable handling.

Using ENV JAVA_HOME instead of inline export is a Docker best practice that makes the environment variable available to all subsequent layers and improves maintainability.


54-54: LGTM! Plugin path aligns with JDT.LS conventions.

The updated destination /jdtls/plugins/ matches the expected plugin loading path for JDT.LS, ensuring the Java Analyzer Bundle is correctly discovered at runtime.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/SymbolProviderResolver.java (2)

18-18: LGTM! Enum constant provider registered correctly.

The mapping for location type 6 correctly routes to EnumConstantSymbolProvider, which handles enum constant references as documented in the integration test suite.


23-23: LGTM! Package declaration provider registered correctly.

The mapping for location type 11 correctly routes to PackageDeclarationSymbolProvider, completing the 100% location type coverage mentioned in the PR objectives.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/ReturnTypeSymbolProvider.java (2)

10-10: LGTM! Enhanced matching with readable type conversion.

The addition of Signature.toString() to convert JVM type signatures (e.g., "I", "Ljava/lang/String;") to readable type names (e.g., "int", "java.lang.String") significantly improves query usability. Users can now search using human-readable type names instead of JVM internal signatures.

Also applies to: 23-27


34-35: LGTM! Dual matching expands query coverage.

The OR condition signature.contains(s) || readableType.contains(s) ensures that searches succeed whether the query uses JVM signatures or readable type names, improving the user experience.

java-analyzer-bundle.test/projects/test-project/.settings/org.eclipse.jdt.core.prefs (1)

1-9: LGTM! Eclipse JDT configuration aligns with test environment.

The preferences file correctly configures the test project for Java 17 compilation, matching the Java 17 environment used throughout the integration test infrastructure.

java-analyzer-bundle.test/docs/integration-tests.md (1)

1-1028: Excellent comprehensive documentation!

This documentation provides outstanding coverage of the Phase 2 integration testing framework:

✅ Clear architecture diagrams and component descriptions
✅ Detailed test scenarios with code examples for all 15 location types
✅ Troubleshooting guidance and debugging tips
✅ Coverage matrix showing 100% location type testing
✅ Migration use case examples (javax→jakarta, Spring patterns)
✅ Multiple execution methods (local, container, CI/CD)

The documentation will be extremely valuable for developers working with the integration test suite.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/EnumConstantSymbolProvider.java (1)

23-47: LGTM! Enum constant provider follows established patterns.

The implementation correctly:

  • Validates the element is a FIELD (line 29)
  • Filters for enum constants using isEnumConstant() (line 33)
  • Constructs SymbolInformation following the same pattern as other providers
  • Handles exceptions with appropriate logging

The provider integrates well with the symbol resolution framework and enables location type 6 (enum constant) searches as documented in the integration tests.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/Dockerfile (1)

5-5: Verify Java 11 compatibility of the test project.

The base image has been upgraded from Java 8 (maven:3.6-jdk-8-slim) to Java 11 (maven:3.8-openjdk-11). While this aligns with the broader test infrastructure using Java 17, ensure that the customers-tomcat-legacy project code is compatible with Java 11, particularly:

  • Any deprecated APIs removed in Java 11
  • Libraries that may not support Java 11
  • Build configuration in pom.xml targeting the correct Java version

Run the following script to verify the build succeeds:

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/exception/ResourceNotFoundException.java (1)

19-27: LGTM!

Standard exception implementation following best practices with proper serialVersionUID and constructor delegation.

Dockerfile.test (1)

1-54: LGTM!

Well-structured multi-stage build that efficiently creates a test environment with JDT.LS, Fernflower, Maven tooling, multiple JDK versions, and Go support. The stage separation minimizes final image size and build cache efficiency.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/SampleDelegateCommandHandler.java (5)

167-168: LGTM!

Helpful comment clarifying that package searches always use PATTERN_MATCH due to Eclipse JDT's flexible package matching semantics.


183-186: Good enhancement for parameterized type matching.

Adding R_ERASURE_MATCH for return types and variable declarations enables matching parameterized types (e.g., List<String> when searching for java.util.List), improving search coverage for generic types.


194-195: Good enhancement for parameterized constructor matching.

Adding R_ERASURE_MATCH for constructor calls enables matching parameterized constructors (e.g., ArrayList<String> when searching for java.util.ArrayList).


199-200: Good enhancement for parameterized field type matching.

Adding R_ERASURE_MATCH for field declarations enables matching parameterized field types.


205-207: LGTM!

Correctly handles enum constants as FIELD references, improving search completeness.

java-analyzer-bundle.core/src/main/java/io/konveyor/tackle/core/internal/symbol/PackageDeclarationSymbolProvider.java (1)

20-71: LGTM!

Well-structured logic that correctly handles different element types (IPackageDeclaration, ICompilationUnit, IPackageFragment) with appropriate defensive checks and logging.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/model/Customer.java (1)

11-98: LGTM!

Standard JPA entity implementation with appropriate column mappings, sequence generation, and accessor methods. The entity follows best practices for a simple data model.

java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/java/io/konveyor/demo/ordermanagement/repository/CustomerRepository.java (1)

1-8: Straightforward Spring Data repository – looks good.

CustomerRepository cleanly extends PagingAndSortingRepository<Customer, Long> without extra complexity. No issues from a test-fixture perspective.

Comment on lines +118 to +128
private static class VariableInfo {
String name;
int offset;
int length;

VariableInfo(String name, int offset, int length) {
this.name = name;
this.offset = offset;
this.length = length;
}
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Remove unused fields or utilize them properly.

The VariableInfo class captures offset and length fields (lines 125-126), but these are never used in the symbol creation loop (lines 100-109). This indicates an incomplete fix—these fields were likely added to build accurate locations for each variable, but that implementation was never completed (see issue at lines 107-108).

Either:

  1. Use these fields to construct proper locations (as suggested in the comment above), or
  2. Remove the unused fields if you decide they're unnecessary

Comment on lines +1 to +6
jdbc.driverClassName=oracle.jdbc.driver.OracleDriver
jdbc.url=jdbc:oracle:thin:@169.60.225.216:1521/XEPDB1
jdbc.user=customers
jdbc.password=customers
hibernate.hbm2ddl.auto=create-drop
hibernate.dialect=org.hibernate.dialect.OracleDialect No newline at end of file
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Avoid committing real DB credentials and non-local endpoints, even in test fixtures.

This file hardcodes a real-looking IP and cleartext DB credentials. If these point at anything other than a throwaway local container, this is a security/compliance risk, and hbm2ddl.auto=create-drop could be destructive.

Consider:

  • Switching to localhost/container networking instead of a fixed external IP.
  • Replacing credentials with obviously fake sample values, or injecting them via env/overrides.
  • Rotating any real credentials that may have been exposed by this commit.
🤖 Prompt for AI Agents
In
java-analyzer-bundle.test/projects/customers-tomcat-legacy/src/main/resources/persistence.properties
lines 1-6, the file contains hardcoded DB host, IP and cleartext credentials
plus hbm2ddl.auto=create-drop; replace the external IP with localhost or a
container network alias, remove or replace real credentials with obviously fake
placeholders or reference env vars/system properties (e.g. ${DB_USER},
${DB_PASS}, ${JDBC_URL}) so test fixtures don’t contain secrets, and change
hbm2ddl.auto away from create-drop for non-local runs (or guard it behind a
test-only profile); if these credentials were ever real, rotate them immediately
and use overrides for CI/local config instead of committing secrets.

Signed-off-by: Shawn Hurley <[email protected]>
Signed-off-by: Shawn Hurley <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant