Hi, Sahoo; first, thanks for replying to my message and pointing out my (boneheaded) error.
Let me explain a little more about how this application is composed and see (if you're willing) what you think the best option is.
The application is mostly a bundle of fairly tiny library jars and a couple of EJBs that use them. The library jars define pojos, not entities.
The first thing I'd like is for the [i]application[/i] to designate those pojos as entities. I understand this more than likely commits me to orm.xml files instead of @Entity annotations, since the library jar files containing the pojos should have no idea that they're about to be used as entities. I'm fine with that. Or at least I know that I will more than likely have to override some annotations with XML.
Next, the EJBs in the mix are stateless session beans that inherit from a common abstract base class. For convenience's sake, since all of these EJBs need to work with an EntityManager, I've put the EntityManager in the abstract base class. I [i]had[/i] been annotating this EntityManager with the @PersistenceContext annotation--but of course the EJB jars don't know what application they're going to be part of, so they don't know what persistence unit to refer to here. So I was relieved to see that I could leave the unitName attribute off here.
So, then: what is the recommended strategy for the following deployment scenario?
1. Library jars are maximally reusable. They define pojos and interfaces. They know nothing about J2EE.
2. EJB jars have very little non-default information in them, and no ejb-jar.xmls by default. Any annotations they may have (security stuff, transactions, whatnot) are as generic/general as possible. I'd [i]like[/i] to have them be able to refer to EntityManagers without having to jump through JNDI hoops--i.e. via resource injection via the @PersistenceContext annotation, but I am still somewhat confused about how to do this given that I don't know [i]a priori[/i] what persistence unit they're going to be working with.
3. The application (.ear) itself may be customized--customers should be able to throw in their own EJB jars, their own entities, etc. that (hopefully) extend from the base application's.
The more I'm looking at all this, the more I'm thinking that annotations are simply not the proper tool at all for this scenario--they're better when one is, for example, both the Bean Provider and the Application Assembler.
Thanks for any insight you can provide, and for your continued invaluable help on this forum over the years.
Best,
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=262558