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

[Story] "Test connection" feature #592

Closed
2 tasks done
andrewazores opened this issue Oct 28, 2022 · 2 comments · Fixed by #920
Closed
2 tasks done

[Story] "Test connection" feature #592

andrewazores opened this issue Oct 28, 2022 · 2 comments · Fixed by #920
Assignees

Comments

@andrewazores
Copy link
Member

andrewazores commented Oct 28, 2022

As a user, I do not want to have to update a connection configuration, attempt to load a content view, and then delete and recreate my connection configuration if I entered the wrong values by mistake.

@andrewazores andrewazores added good first issue Good for newcomers feat New feature or request labels Oct 28, 2022
@tthvo tthvo self-assigned this Oct 28, 2022
@tthvo tthvo moved this to Todo in 2.3.0 release Nov 1, 2022
@andrewazores andrewazores moved this from Todo to In Progress in 2.3.0 release Nov 3, 2022
@tthvo
Copy link
Member

tthvo commented Nov 4, 2022

Looks like we need to define an API endpoint to open a probe connection to the target. Just wondering if we can safely use any existing endpoint for this purpose?

Maybe reusing the v2/targets with verb POST to specify a parameter ?probe=true and the backend can stop before adding the target to discovery tree?

@andrewazores
Copy link
Member Author

I think reusing the existing custom targets definition endpoint makes sense. I would probably call the parameter dryrun or something, but probe could work too - though we already use that term in relation to the JMC Agent and inserting bytecode.

That endpoint handler is already basically set up to do what we need it to, since it will attempt to open a connection to the target and retrieve its hash ID before adding it to the discovery database. So the probe/dryrun parameter would just skip that last step. It looks like the handler also needs to notify the JVM ID cache to invalidate the ID entry if the definition is not actually added to the database, or maybe instead a way to retrieve the JVM ID without caching the result to begin with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants