Dependency Injection: Diagnostics for non-static inner class managed bean
A top-level Java class is a managed bean if it is defined to be a managed bean by any other Jakarta EE technology specification, such as the Jakarta Faces technology specification, or if it meets all the following conditions.
- It is not a nonstatic inner class.
Diagnostic
- Identify the field/method/constructor annotated with
@Inject - Check if the dependency class is contained in the same file as an inner class
- If the dependency class is NOT
static, deliver a diagnostic error that the dependency class must bestatic
Quick Fix
- Remove
@Injectannotation - Suggest adding
staticmodifier to class declaration
Example
The following is a faulty code snippet example
@WebServlet(name = "diUnStat", urlPatterns = { "/diUnStat" })
public class GreetingServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Inject
private GreetingA greeting;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
res.setContentType("text/html;charset=UTF-8");
res.getWriter().println(greeting.greet("Bob"));
}
// Missing `static` modifier
@ApplicationScoped
public class GreetingA {
public String greet(String name) {
return "GreetingA, " + name;
}
}
}
[INFO] [ERROR ] CWWKZ0004E: An exception occurred while starting the application demo-servlet. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type GreetingA with qualifiers @Default
[INFO] at injection point [BackedAnnotatedField] @Inject private io.openliberty.sample.jakarta.di.unsatisfied.stat.GreetingServlet.greeting
[INFO] at io.openliberty.sample.jakarta.di.unsatisfied.stat.GreetingServlet.greeting(GreetingServlet.java:0)
Related to #153
Would you be interested in submitting a patch that fixes it? The relevant piece of code would be https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/internal/keys/show/ShowKeysUI.java
I had a look at this. getShell().getCaret() is giving me null and because of that I am unable to detect the overlap. Any suggestions ?
I think it would feel strange when the window showing the shortcut opens at different locations.
The window showing the shortcut has some transparency to mitigate the issue that it could overlap with some important part of the workbench. Maybe we could increase the transparency a bit more.
I think it would feel strange when the window showing the shortcut opens at different locations.
The window showing the shortcut has some transparency to mitigate the issue that it could overlap with some important part of the workbench. Maybe we could increase the transparency a bit more.
@BeckerWdf Thanks for the suggestion. This looks reasonable to me.
@frankbenoit Are you ok with this approach? Let me know. If yes I will investigate on this.
@frankbenoit: Are you ok with the proposed change?
Yes, if the editors writing/cursor is good readable this is fine.