A long standing open debate within the Domain-Driven Design (DDD) community is whether entities should be able to access application services (roughly business facades in J2EE patterns parlance) and repositories (roughly DAOs in J2EE patterns parlance). If we think it's OK for entities to access these parts of the application, it poses a problem in JPA and other mainstream data access technologies - how do you inject objects into an entity? The answer today in JPA is that you can't do that. There are good technical reasons why it's difficult to allow CDI injection directly into JPA entities - it becomes very difficult to figure out how to manage the entity life-cycle if it is managed by both the CDI and JPA runtimes at the same time.
So is there a solution to this problem? The good news in JPA 2.1 and Java EE 7 is that there is a clever workaround. While you can't use CDI injection in entities, entity listeners now fully support injection. If needed you can then pass in an appropriately scoped injected object (probably an application scoped bean) into the entity or anything else that you need from the entity listener. This is exactly the technique demonstrated by Hantsy Bai in explaining CDI support in JPA 2.1 entity listeners. Besides entity access to services and repositories, being able to use injection in entity listeners is generally very helpful for more complex cross-cutting concern like requirements at the JPA layer. Prior to JPA 2.1 both Apache CODI and Seam 3 enabled injection into JPA entity listeners.
If you happen to need a basic introduction to JPA entity listeners, Alexandre Gama has one of the best compact write-ups I've seen so far.
For the record, I do think accessing application services and repositories in entities violates the separation of concerns principle and should be done very sparingly :-).
Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company.