Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Java provider rules not triggering for patterns ending with * or (*) #736

Open
1 task done
joe-braley opened this issue Nov 21, 2024 · 5 comments
Open
1 task done
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates an issue or PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@joe-braley
Copy link

joe-braley commented Nov 21, 2024

sample1.zip

Is there an existing issue for this?

  • I have searched the existing issues

Konveyor version

v0.6.0-alpha.2

Priority

Major

Current Behavior

Hi team!

I have created sample Java files to test analysis against. When running assessments, we noticed rules with patterns ending in * or (*) are not triggering. This results in missing issues in the generated static report.

For the attempt I have run for this issue the command I ran was:
./kantra analyze --input ./sample1/ --target azure-appservice --output ./sample1-output --overwrite

I believe on the sample code, which is attached, this app-service rule should have triggered and added an incident in the static report. However, I only observe a single rule being triggered with respect to Windows style pathing in the code.

Please let me know if I performed any steps/categorized incorrectly! This is my first issue in this repo 😄

Expected Behavior

The rule linked above would trigger and additional incidents would appear in the static report.

How Reproducible

Always (Default)

Steps To Reproduce

  1. Download the sample Java code attached to this issue.
  2. When running an assessment, set the target to azure-appservice.
  3. Execute the assessment.
  4. Observe that the rule "09-eap-to-azure-appservice-environment-variables.windup.yaml" with the following patterns did not return results:
    • java.referenced:
      location: METHOD_CALL
      pattern: java.lang.System.getenv(*)
    • java.referenced:
      location: METHOD_CALL
      pattern: java.lang.System.getProperty(*)

Environment

version: v0.6.0-alpha.2
SHA: 2f22d6db9f4ed5e64ba211af082fd8e9de9b7e01
image: quay.io/konveyor/kantra

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

Python 3.11.2
Java 17.0.13+11

Anything else?

The result of the latest analysis on the attached sample I performed using the above Kantra version. Yields only one issue:
Image

This view is to show the sample code with the Java function calls. I believe we should see more issues when these are present in the code.
Image

@joe-braley joe-braley added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 21, 2024
@konveyor-ci-bot
Copy link

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

@konveyor-ci-bot konveyor-ci-bot bot added the needs-priority Indicates an issue or PR lacks a `priority/foo` label and requires one. label Nov 21, 2024
@joe-braley
Copy link
Author

CC @kthatipally

@github-project-automation github-project-automation bot moved this to 🆕 New in Planning Nov 21, 2024
@jmle
Copy link
Contributor

jmle commented Nov 22, 2024

I have been taking a quick look at this and it seems that there is a problem when matching method calls in general. We will need to take a deeper look into it.

@jmle
Copy link
Contributor

jmle commented Nov 27, 2024

I have discovered some things after investigating. Having a System.getenv() call in the code:

  • getenv and getenv() both work.
  • getenv* also works
  • When having methods with argument types (for instance, rest.getForObject(new URI("http://www.example.com/"), Source.class);), the following works: getForObject(*,*) and getForObject(URI,Class<Source>) The following does not: getForObject(*).
  • Qualifying the method in the previous example works, ie looking for org.springframework.web.client.RestTemplate.getForObject, but having System.getenv() in the code and looking for java.lang.System.getenv does not.

My conclusions after this:

  • There seems to be a problem when trying to look for static method calls in the LS. I am not sure what's causing this. A potential fix would be to change these rules to an and condition requiring both the call getenv and the class System to be used in the same file. More needs to be investigating, maybe trying to contact the Eclipse people.
  • The (*) pattern only works if there is a single argument to the method, otherwise it doesn't. There must be as many * as arguments in the method. Some rules may need a fix.

FYI @rromannissen @dymurray

@shawn-hurley
Copy link
Contributor

I wonder if for method searches it makes sense to remove the arguments if there is a (*) assuming that the rules want to find all overloaded methods.

As for the static functions, I do wonder if there is a special parameter that we have to add in the search to consider these?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates an issue or PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants