1. Yes, annotations are meant for developers, but they can always be
overridden by assembler or deployer by using respective xml descriptors.
In case of entities, it is orm.xml and for ejbs, it is ejb-jar.xml. So,
if a developer has made certain assumption about the runtime environment
which is not true during depoyment, deployer can override it. Certain
annotations( are not allowed to be overridden, because that's too
dangerous to do. e.g., changing bean type from Stateful to Stateless is
not allowed.
2. Injection can be achieved without use of annotation. Look at chapter
#5 of the Java EE platform spec. This should take care of injection of
PersistenceContext into your EJBs. No, you can't inject into a super
class, so you have to inject into a field or method of the actual EJB. I
would do something like this:
public class BaseEJB {
public abstract EntityManager getEM();
}
@Stateless
public class MyEJB extends BaseEJB {
EntityManager em;
public EntityManager getEM() { return em;}
}
ejb-jar.xml
<enterprise-beans>
<session>
<persistence-context-ref>
<persistence-context-ref-name>jpa/em</persistence-context-ref-name>
<injection-target>
<injection-target-class>MyEJB</injection-target-class>
<injection-target-name>em</injection-target-name>
</injection-target>
</persistence-context-ref>
</session>
</enterprise-beans>
Try something like this:
1. Annotate your entity POJOs with JPA annotations that define the
object model of your entity (e.g. @Entity, @Embeddable, @Id, etc.). They
are less likely to vary between different usages of the entities. What
changes is the relational mapping information, like, table name, column
name, id generation scheme, etc. Use orm.xml to provide these
information at the point of use.
2. Keep persistence.xml and orm.xml as part of your ejb-jar.
Hope this helps,
Thanks,
Sahoo
glassfish_at_javadesktop.org wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>