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

LSP4Jakarta quick fixes not appearing (e.g. for @WebServlet annotation attributes ) #377

Closed
scottkurz opened this issue May 12, 2023 · 4 comments · Fixed by #471
Closed
Assignees
Labels
bug Something isn't working with the product high priority should-fix
Milestone

Comments

@scottkurz
Copy link
Member

scottkurz commented May 12, 2023

With LTE 0.9.0 on Eclipse v4.27 Enterprise Java,

When using an empty @WebServlet annotation I see the diagnostic message: The annotation @WebServlet must define the attribute 'urlPatterns' or 'value'. but the only quick fix I see is for generating OpenAPI annotations.

image

@scottkurz scottkurz added bug Something isn't working with the product should-fix labels May 12, 2023
@scottkurz scottkurz added this to the 23.0.1 milestone May 12, 2023
@scottkurz scottkurz self-assigned this May 16, 2023
@scottkurz scottkurz changed the title LSP4Jakarta quick fix for @WebServlet annotation attributes not appearing LSP4Jakarta quick fixes not appearing (e.g. for @WebServlet annotation attributes ) May 18, 2023
@scottkurz scottkurz removed this from the 23.0.6 milestone Jun 13, 2023
@scottkurz
Copy link
Member Author

Noting if I delete the WebServlet import, and click on the QF to import it:

image

the LSP4Jakarta QF appears at this point. If I go on to make another unrelated change before clicking on this now-showing QF, however, the problem re-appears.

@scottkurz
Copy link
Member Author

One clue here in preparing LTE v23.0.9 on top of v4.28. We tried removing the jdt.ls dependency altogether since it is only needed by the LTE LSP4MP client (the LSP4Jakarta path provides the "JDTUtils" function from a copy shipped within LSP4Jakarta).

When we removed the jdt.ls bundle, this problem went away.

Would it help to, in the debugger, add breakpoints to the JDT LS function related to the code action path, and see how it might be getting in the way?

@scottkurz
Copy link
Member Author

interestingly enough... I tried doing like Quarkus kinda did, telling LSP4MP we were using our own JDTUtils so as not to require the jdt.ls bundle again... and for "our own" I mostly delegated to the LSP4Jakarta one.

So.. it basically seemed to "work" ... the MP function was back. Two things I didn't implement: fetching source and fetching Javadoc..the latter looked like a bigger deal but haven't noticed where it surfaces yet.

However, the QF problem is back ! It's not fixed even without the jdt.ls bundle (ie removing that).

One might interpret that as something like.. it's the combination of LSP4Jakarta and LSP4MP each doing their own QF stuff that is the problem... rather than the code in jdt.ls specifically interacting with our LTE LSP4E code.

@scottkurz
Copy link
Member Author

Workaround seems to be to ensure the MP OpenAPI dep is not on the path... e.g.:

		<dependency>
			<groupId>org.eclipse.microprofile</groupId>
			<artifactId>microprofile</artifactId>
			<version>6.0</version>
			<type>pom</type>
			<scope>provided</scope>
			<exclusions>
				<exclusion>
					<groupId>org.eclipse.microprofile.openapi</groupId>
					<artifactId>microprofile-openapi-api</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working with the product high priority should-fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant