I have posted a rather detailed "Duh?" question over on the Glassfish forums (as is my wont): http://forums.java.net/jive/thread.jspa?messageID=483195񵽻
Briefly (please see that post for further details), I realize that I do not understand how Weld in a JCDI world processes @EJB references.
I have a servlet, which is part of a web application, which is also a bean archive, by virtue of having a WEB-INF/beans.xml file.
That servlet has an @Inject-annotated field, which is not of concern here, which is the main reason I declared the web app a bean archive.
The servlet also has several @EJB annotations (which are VERY MUCH of concern here).
Each @EJB-annotated field is declared as a particular kind of interface. That interface is, in all cases, a specialization of a super interface.
(All such interfaces are housed in different jar files in the enclosing ear file's lib directory. None of those jar files is declared to be a bean archive, because I simply don't require Weld services.)
Weld nevertheless appears to take over the handling of these @EJB fields. Consequently I am not surprised that it has no idea what the types are, because none of the jar files that house the types are declared as bean archives.
Much to my surprise however, it appears to understand the *immediate* interface. It is only when it starts investigating the super interface that all hell breaks loose.
It appears that under Glassfish at any rate the super interface is treated as though it were an EJB remote interface (?!) even though I have specifically annotated my EJB to prohibit usage of remote interfaces (via the @Local({ SubInterface.class }) convention).
I am so turned around and mystified by all this that I don't know whether to file a bug against Glassfish, Weld or my own damn brain. Any pointers are gratefully appreciated.
Best,
Laird
