[DELTASPIKE-319] Fail deployment of app with JPA module when EM not found in same class.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Won't Fix
• Affects Version/s: 0.3-incubating
• Fix Version/s: 0.4
• Component/s: JPA-Module
• Assignee: John D. Ament
• Reporter: Gabriel Sosa
• Created: 12/Mar/13 11:36
• Updated: 02/Jun/13 10:26
• Resolved: 13/Mar/13 03:42

Description

I stumbled upon this by coincidence and it gave me major headaches as it was a bit hard to realize why and where it happened.

I started using Picketlink 3.0.0.alpha1 and it provides an IdentityManager that handles precisely that. Now the problem is that after looking at Deltaspike's source code for a while, it does the following:

On a method annotated with @Transactional:

@Transactional
public void myTransactionalMethod() {
identityManager.createUser("foo");
}

As far as I understand, the module needs to know which EntityManager should execute within a transaction, so basically it first scans the annotation (@Transactional) looking for qualifiers, if it finds a qualifier, it performs some checks then starts a transaction. If the annotation does not have a qualifier, then it takes the class that has the @Transactional method, and starts scanning its fields to find the EntityManager used and get its qualifier, if it finds an EntityManager it will take its qualifier. This is expected behaviour but the problem arises when the class calling the transactional method does not have an EntityManager because it doesn't need one.
Say in this scenario:

Public class IdentityManager {

protected EntityManager doBlackMagicToGetAnEntityManager()

{ //find an entitymanager..... }

public void createUser(String username)

{ doBlackMagicToGetAnEntityManager().persist(new User(username)); }

}

@Named
@RequestScoped
public class VictimBean {

@Inject
IdentityManager identityManager;

protected String name;

@Transactional
public void doCreate()

{ identityManager.createUser(this.name); }

}

Deltaspike will look for a qualifier, won't find it in Transactional. Therefore, it will scan VictimBean looking for a qualifier for an EntityManager, it won't find one, it won't open a transaction, the application throws an exception because createUser(..) modifies the database and is required to be executed within a transaction.

Is this behavior expected? Because it is very unpredictable. I didn't really see it coming.

PicketLink requires me to use a @PicketLink qualifier in a field producer so it can get an entity manager but I have this in my Resources bean, which doesn't directly participate in that code.

Issue Links

• is duplicated by: DELTASPIKE-320 moving the entity-manager injection can break the default handling
• relates to: DELTASPIKE-320 moving the entity-manager injection can break the default handling