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: | suspicious messages for @Injection | ||
---|---|---|---|
Product: | javaee | Reporter: | muellermi <muellermi> |
Component: | CDI | Assignee: | Denis Anisimov <ads> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arungupta, dorssel, dwuysan, pjiricka, sebastianovide |
Priority: | P3 | ||
Version: | 7.1 | ||
Hardware: | PC | ||
OS: | Windows 7 x64 | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
muellermi
2011-09-08 14:17:28 UTC
(In reply to comment #0) > Product Version = NetBeans IDE Dev (Build 201109060600) > Operating System = Windows XP version 5.1 running on x86 > Java; VM; Vendor = 1.7.0 > Runtime = Java HotSpot(TM) Client VM 21.0-b17 > > @Inject private Conversation _conversation; > false NetBeans warning: Unsatisfied dependency: no bean matches the injection > point > off course there is no bean, but it's a valid injection Why it is valid injection ? Please describe it in details. > > > @Inject > private SessionController _sessionController; > false NetBeans warning: No enabled eligible for injection beans are found > The bean is a named session bean, thus it is eligible Also don't see details. What is the SessionController ? OK, the Conversation is the javax.enterprise.context.conversation.Conversation interface with @Default qualifier and @RequestScoped. By the CDI spec its built-in type which is provided by the container. So there could be no explicitly enabled bean. CDI warnings should ignore such injection. I will fix it. Still has no information what is SessionController . What is FQN, its Java type definition , what qualifiers it has . Is it class in compile classpath or in the source ? I can't realize the problem without this information. (In reply to comment #2) > OK, the Conversation is the javax.enterprise.context.conversation.Conversation > interface with @Default qualifier and @RequestScoped. The CDI spec lies about the scope. So it seems this is the truth: Conversation is the javax.enterprise.context.Conversation. It's name javax.enterprise.context.conversation. And it has @ConversationScoped scope. This is from JavaDoc. The spec tells that it has @Default qualifier and it has @RequestScoped scope. The last thing is false I think. Fix for Conversation and Context interfaces : web-main#6971324f5d17 Additional information from reporter : SessionController has definition @Named @SessionScoped public class SessionController implements Serializable { I'm able to reproduce it. Will investigate. 1) SessionController has @SessionScoped scope. The last scope is a normal scope. It means that controller requires create a proxy for required type. 2) You are using SessionController as REQUIRED TYPE for injection point. This is a class which means it has all methods inherited from Object class which has a number of final methods. Final methods cannot be proxied. That's why SessionController eligible for injection element BUT it is disabled. You can realize it via Inspect CDI action. This is by the CDI spec. So this is not an issue. To resolve your problem one needs to refactor interface from SessionController . This interface should set as required type in injection. Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/6971324f5d17 User: Denis Anisimov <ads@netbeans.org> Log: Fix for built-in scope bean types : Context and Conversation , BZ#201825 - suspicious messages for @Injection *** Bug 205914 has been marked as a duplicate of this bug. *** Injections with a normal scoped bean *class* as REQUIRED TYPE are allowed by the CDI spec, and they are proxyable. Denis is probably referring to section 5.4.1 "Unproxyable bean types" where it says "classes which are declared final or have final methods". However, from the next section it is clear that the final methods of java.lang.Object are excluded: "5.4.2. Client proxy invocation ... The behavior of all methods declared by java.lang.Object, except for toString(), is undefined for a client proxy. Portable applications should not invoke any method declared by java.lang.Object, except for toString(), on a client proxy." This type of injection is similar to the no-interface view injection of EJB 3.0. So to resolve this issue the trigger for this warning should exclude the final methods of Object. OK, agreed. Thanks for clarification. web-main#559756a3542a Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/559756a3542a User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#201825 - suspicious messages for @Injection I'm injecting a bean marked with @Named and @ConversationScoped but I'm using the CODI conversation scope type: org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped The warning I'm seeing is since upgrading to NB7.1 is: "No enabled eligible for injection beans are found" I realize it's not a built in scope but this is a valid injection as far as I can tell (the application works fine) so I'd rather not be seeing a warning if possible. (In reply to comment #13) > I'm injecting a bean marked with @Named and @ConversationScoped but I'm using > the CODI conversation scope type: > org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped > > The warning I'm seeing is since upgrading to NB7.1 is: "No enabled eligible for > injection beans are found" > > I realize it's not a built in scope but this is a valid injection as far as I > can tell (the application works fine) so I'd rather not be seeing a warning if > possible. same here: @Inject ConfigHelper config; and ConfigHelper is @Named @ApplicationScoped public class ConfigHelper implements Serializable{ ApplicationScoped, org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped and originally reported RequestScoped are Normal scopes ( see CDI spec ). So this bug is the same for any of them. The bug is FIXED. It is fixed in the 7.2. Use the development build for check the fix. *** Bug 208335 has been marked as a duplicate of this bug. *** |