Hi; looks like CDI is still not working properly in GlassFish 3.1.2. :-(
Or I haven't put beans.xml files in the right place (though I've put them
everywhere the Weld authors have told me personally to put them).
I have a JAX-RS application (a .war file) contained in an .ear file. It
(deliberately) does not have a beans.xml in it since it does not contain
any beans. In fact, it does not have any jars or classes in the lib
directory, or in the classes directory. (How can this be? Answer: It
relies on jar files in its enclosing .ear file's lib directory instead.
Those are the JAX-RS resources it aggregates.)
So in the enclosing .ear file's lib directory, I have a jar containing a
JAX-RS class (UserInfoResource). It has a META-INF/beans.xml file in it
since (as you will see below) this class is a target for CDI injection.
That resource class has something like this:
@Inject
private UserInfoManager userManager;
UserInfoManager in turn is an interface (nothing special). It is packed up
in a jar file in the ear file's lib directory. I did not put a beans.xml
in there initially (per the Weld authors' instructions); then went ahead
and added one anyway.
Next, there is an EJB jar as well that contains a stateless session bean
(UserInfoManagerBean) that implements UserInfoManager. It has a
META-INF/beans.xml file since it is a source of CDI "injectables" and
therefore needs to be a bean archive.
So: resource class needs an implementation for UserInfoManager; EJB
implements UserInfoManager; both the EJB and resource jars are bean
archives.
Injection fails in the resource class:
remote failure: Error occurred during deployment: Exception while loading
the app : WELD-001408 Unsatisfied dependencies for type [UserInfoManager]
with qualifiers [@Default] at injection point [[field] @Inject private
com.foobar.jaxrs.UserInfoResource.userManager]. Please see server.log for
more details.
The specification indicates that Weld should discover the (only)
implementation of UserInfoManager (an EJB implementation) and should
automatically inject it here. As has been true for many versions of
GlassFish over the years, it does not.
I have tried using @Typed(UserInfoManager.class) as well on the
UserInfoManagerBean to really express my intention that THIS was the only
bean type I wanted it to have; this had no effect. Neither did using
@Local(UserInfoManager.class) to express my intent that this should be the
only business interface implemented by the EJB.
What other places should I attempt to put a beans.xml in? Or what obvious
pilot error am I committing?
Lastly, it now takes around 10 minutes for GlassFish to attempt (and fail)
to deploy my ear file. I assume this is just due to the insane amount of
scanning and resolving that Weld has to do? Deployment now triggers the
"idle thread" bug (
http://www.java.net/forum/topic/glassfish/glassfish/interrupting-idle-thread?force=453)
and requires that AS_ADMIN_READTIMEOUT be set to a staggeringly huge number
just so that I can see the Weld error that is output.
I know the drill; I will boil this down into a test case.
Best,
Laird
--
http://about.me/lairdnelson