This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Unsatisfied dependency: no bean matches the injection point - when it's provided by server | ||
|---|---|---|---|
| Product: | javaee | Reporter: | Martin Fousek <marfous> |
| Component: | CDI | Assignee: | Sergey Petrov <sj-nb> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | chaase3, kganfield, pjiricka |
| Priority: | P3 | ||
| Version: | 7.3.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | testing bean | ||
Is providing by server defined by @JMSConnectionFactory? If yes, cdi may need just to skip any injection points with additional JMSConnectionFactory annotation. (In reply to comment #1) > Is providing by server defined by @JMSConnectionFactory? > If yes, cdi may need just to skip any injection points with additional > JMSConnectionFactory annotation. I'm afraid that the @JMSConnectionFactory is only optional information since the Java EE 7 specification guarantees default connection factory provided by the Java EE 7 compliant server. It means that probably all injections of JMSContext should be probably excluded from the hints check. See https://jms-spec.java.net/2.0/apidocs/javax/jms/JMSContext.html: "Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container." ok, in this case either there should be no warning for javax.jms.JMSContext or for javax.jms.*. Especially if default implementation should be always provided by ee7 server. If there is any case when it may fail it's possible to introduce separate info-warning. The bug is even wider than that with the above mentioned JMSContext. Netbeans is saying exactly the same when encountering injections which are explicitly stated as predefined beans in Java EE 7: http://docs.oracle.com/javaee/7/tutorial/doc/cdi-adv004.htm#CJGHGDBA In my case it's HttpSession. Good point Oswald. All these classes should be excluded from the validation as well (at least in case of Java EE 7). Integrated into 'main-silver', will be available in build *201312110002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/89d0e9a4381d User: Sergey B. Petrov <sj-nb@netbeans.org> Log: #226552 handle context and servlets predefined injections, refactor #234279 Thanks, works well. |
Created attachment 131750 [details] testing bean Product Version: NetBeans IDE Dev (Build 20130222-4978d080f8dc) Java: 1.7.0_06; Java HotSpot(TM) 64-Bit Server VM 23.2-b09 Runtime: Java(TM) SE Runtime Environment 1.7.0_06-b24 In the ee7 project will be generated source for sending MDB which is marked with warning 'Unsatisfied dependency: no bean matches the injection point'. It's there probably since the JMXContext is not provided by the project but from the application server. I don't know whether we have a way how to tell the CDI support which injection points will be injected by the server and that it's ok. I'm attaching sample source of the MDB - which will be standard generated one in ee7 projects.