Discussion :

[grediN-]

Salut à tous

Je sais que c'est loin d'être la première fois que ce genre de topic apparaît sur ce forum et je m'en excuse j'ai fait un bon tour sur le net, j'ai trouvé beaucoup de posts traitant de ce problème, mais aucun n'apportait de réponses précise et claire, voire même pas du tout

Je débute avec Java EE et je ne compte plus le nombre de fois ou je tente de tout refaire à partir d'un projet vierge, le nombre de re-initialisations & reboot de Glassfish J'ai toujours l'objet EntityManager à NULL.

Voici le code de ma Session Bean :

Interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
@Remote
public interface HellServiceRemote
{
    List<User> GetUsers();
}

Bean :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
@Stateless
public class HellServiceBean implements HellServiceRemote
{
    @PersistenceContext(unitName="Hell_EJBPU")
    private EntityManager em;
 
    @PostConstruct
    public List<User> GetUsers()
    {
        return em.createQuery("SELECT t FROM USERS AS t").getResultList();
    }
}

PersistenceUnit.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="Hell_EJBPU" transaction-type="JTA">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <jta-data-source>jdbc/sample</jta-data-source>
    <properties>
      <property name="toplink.ddl-generation" value="create-tables"/>
    </properties>
  </persistence-unit>
</persistence>

Appel au service sur le projet Java Web

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
dataService = new HellServiceBean();
dataModel = new ListDataModel(dataService.GetUsers());

Merci d'avance !

[Julien_G]

Utilise un objet de type EntityManagerFactory pour forcer l'initialisation de l'EntityManager de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
@PersistenceContext(unitName="Hell_EJBPU")
private EntityManager em;
 
public HellServiceBean()
{
    em = Persistence.createEntityManagerFactory("Hell_EJBPU").createEntityManager();
}
 
@PostConstruct
public List<User> GetUsers()
{
    return em.createQuery("SELECT t FROM USERS AS t").getResultList();
}

[fr1man]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 em = Persistence.createEntityManagerFactory("Hell_EJBPU").createEntityManager();

Ce n'est pas nécessaire, l'entity manager sera créé et injecté par le serveur d'application.

Tu n'as pas d'autres erreurs dans les logs de ton serveur ?

[Heimdal]

Ce n'est pas nécessaire, l'entity manager sera créé et injecté par le serveur d'application.

Vrai, mais pas avec cet appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dataService = new HellServiceBean();

Utilises @EJB sur l'interface locale de préférence si tu l'injecte depuis une servlet ou je ne sais quel objet web managé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
@EJB
private HellServiceLocal

[fr1man]

@ Heimdal
Tout à fait, tu as raison, je n'avais pas fait attention à son appel.

Pour récupérer ton bean, il faut procéder de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Context ctx = new InitialContext();
HellServiceRemote dataService = (HellServiceRemote)ctx.lookup("HellServiceBean /remote");

A utiliser à partir d'une servlet par exemple, sinon, il faut configurer ton context.

EDIT: ou en utilisant l'annotation, comme te l'a indiqué Heimdal

[Heimdal]

Si ton EJB et ta servlet se trouvent dans la même archive java (war ou ear), utilises toujours l'interface locale pour éviter le surcout inutile d'une sérialisation et puis d'une désérialisation.

Sinon "HellServiceBean/remote" c'est du JBOSS il me semble.
Sur Glassfish 2.1, c'est le nom de la classe (avec package), après je ne sais pas pour la V3, peut-être ce sont ils alignés.

[fr1man]

Remote ou local, c'est plus une question de présence dans la même JVM qu'une histoire d'archive.
Je lui montre l'utilisation de la remote, parce que c'est ce qu'il nous montre, après je ne connais pas ses besoins.
Pour le coup du lookup, effectivement, je fais ça sous JBoss, je pensais que c'était standard.

[kalysto]

Non, faire un lookup en cherchant un truc qui n'est pas le forme "java:comp/xxxx" ce n'est pas standard.

Le mieux, c'est de simplement annoter un champ de ton client pour que la reference qui t'interresse soit injectée par le conteneur.

L'annotation à mettre dépend du type de ressource demandée.
En voila quelques exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
@EJB
private LocalInterface ejb;
 
@PersistenceUnit(unitname="persistence-unit-name")
private EntityManagerFactory emf;
 
@PersistenceContext
private EntityManager manager;
 
@Resource
private DataSource source;

Ensuite l'important est que ton client soit géré par un conteneur. Donc il faut que ce soit une servlet, un bean JSF, un EJB ou un vrai client lourd.
J'entends par vrai client lourd une classe (avec un main()) que tu vas executer avec le conteneur d'application cliente de ton serveur d'app.

Par exemple, avec JOnAS, il faut invoker ton client avec le script 'jclient' qui lance le conteneur client. Il existe des scripts similaires pour chaque serveur d'app je suppose.

[fr1man]

Et tu peux également avoir besoin d'un client lourd, non managé, qui accède à un serveur d'application, et donc là, le lookup est intéressant.

[salber]

Je suis loin d’être un expert en EJB3 mais je trouve un peu bizarre le nom le nom du fichier de persistance. Je crois que ce fichier est standard et doit se nommer persistence.xml et non persistenceUnit.xml .
En plus (c’est pas ca le problème ), la signature de la méthode PostConstruct n’est pas correcte. Les méthodes callBack doivent avoir la signature suivante void <METHODE> () .
Et enfin, je crois que tout a été dit par mes prédécesseurs concernant le problème de NullPointer.
NB : un objet managé ne doit pas être instancié par le développeur.