I think perhaps I fundamentally misunderstand the way that Weld interacts with @EJB.
My servlet contains an @Inject field that is where I wish my @SessionScoped object to be injected.
To make this work, I understand that I need to place an empty beans.xml file in the web application's WEB-INF directory, since my servlet class is defined in the war file. That makes sense.
I have removed beans.xml files from everywhere else in my large .ear application.
So it appears that once Weld enters the picture, as it must in order to satisfy an @Inject-annotated field, then all other @EJB annotations in, say, that servlet are handled by Weld as well.
So because there aren't beans.xml files anywhere else in my application (because I erroneously thought I didn't need any, if I'm not using CDI anywhere else in my app), it would appear that Weld jumps in here, and begins trying to figure out what "types" a given ejb reference exposes.
So it runs across my @EJB field, whose type is an interface, of course. That interface is housed in a jar file WITHOUT a META-INF/beans.xml.
So Weld--maybe? and here's the source of my misunderstanding, I suspect--doesn't know anything about that interface, because that interface is housed in a jar file that doesn't have a META-INF/beans.xml file in it. So far so good.
Now, it happens that that interface extends another one from another jar. That super-interface is ALSO not part of a beans archive.
From the stack, which I'll excerpt shortly, it appears that somehow Weld knows or understands or finds or otherwise is not bothered by the [i]sub[/i] interface. (That's mysterious enough, since the sub-interface is not part of a bean archive.)
But it tries to then understand the super interface, which it also doesn't know about, since the super interface is not part of a bean archive either.
It appears that Weld attempts to treat the "unknown" (to it) interface as though it were a [i]remote[/i] EJB interface, as you can see from the following stack trace extract:
[code]
Caused by: java.lang.IllegalStateException: Exception attempting to inject Remote ejb-ref name=com.foo.bar.web.VaadinServlet/personManager,Remote 3.x interface =com.foo.bar.party.api.PersonManager,ejb-link=null,lookup=null,mappedName=,jndi-name=com.foo.bar.party.api.PersonManager,refType=Session into class com.foo.bar.web.VaadinServlet
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:137)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:47)
at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:227)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:181)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:478)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300)
... 28 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Remote ejb-ref name=com.foo.bar.web.VaadinServlet/personManager,Remote 3.x interface =com.foo.bar.party.api.PersonManager,ejb-link=null,lookup=null,mappedName=,jndi-name=com.foo.bar.party.api.PersonManager,refType=Session into class com.foo.bar.web.VaadinServlet
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:684)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:454)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:173)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:130)
... 35 more
[/code]
I have [i]no idea[/i] why it would try to do this.
(In the stack above, you can probably guess that VaadinServlet is the servlet I'm talking about, and that the @EJB field in question houses a PersonManager. What you don't see, however, is that the PersonManager that Weld is [i]trying[/i] to resolve is the SUPER interface. That is, the actual object reference is declared to be a different class than what is exposed here.)
I'm going to try adding beans.xml files pretty much everywhere that could possibly be involved here, but I am very concerned that I no longer understand what is going on. :-)
Best,
Laird
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=483195