> 1) Is there a beans.xml in every JAR meant to receive
> the blessings of CDI?
I thought so. Perhaps I need an extra one. I know it sounds like it, but I'm really not shooting at this randomly in the dark. :-)
In general, I have a garden variety ear file. I err on the side of producing perhaps too many utility jars. This has always served me well in the past. So the business interface for a given EJB and the interfaces and classes for its payloads are in one jar, the convenience superclass of my SLSB is in another, and, of course, finally my SLSB is in an ejb jar at the top level.
The ejb jar itself has a META-INF/beans.xml file in it, since I wish for CDI to recognize it as an artifact that is capable of producing things that can be @Injected elsewhere.
Now, I [i]haven't[/i] put a META-INF/beans.xml file in the jar file that contains the superclass from which my SLSB inherits--and the location of the @PersistenceContext-annotated em field. I was working under the assumption that in this case CDI would not need to be involved, since the abstract superclass is neither a producer nor a @Stateless bean itself. Perhaps I should add a META-INF/beans.xml to it as well? I would be doing this just on faith, however, which doesn't strike me as a good reason. :-)
> 2) Does the structure of your actual final EAR or WAR
> match the structure you intended? (E.g. I've seen
> Eclipse getting stuck in funny states where it would
> forget to copy resource files or class files to the
> appropriate places.)
Thanks for the idea, but yes, I use the command line, Maven 2.2.1 and emacs :-) so I pretty much am the only one in charge of screwing up the packaging. :-) I've triple checked this aspect of it.
Again, the only slightly odd bit here is that my SLSB inherits an AbstractDAO class which itself is not an SLSB--it's abstract, after all (section 4.9.2)--but which houses the EntityManager like this:
[code]
@PersistenceContext
protected EntityManager em;
[/code]
...and that abstract superclass is present in a utility jar in the ear's lib directory.
I didn't see any requirement in the 3.1 specification that said your SLSB's abstract superclass had to be housed in the ejb jar itself, alongside the SLSB implementation class.
> 3) DON'T PANIC :-)
Trying not to think of my deadline. :-)
> Otherwise, a very similar setup works for me, so it
> has to be a tiny nasty difference again...
Hoping so.
Best,
Laird
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=478157