Discussion :

[bug007]

Bonjour à tous,

C'est mon premier post, désolé si c'est pas au top. Merci d'avance de votre aide

Mon soucis est de na pas pouvoir déployer un EJB et de l'utiliser dans une application WEB. J'ai pourtant tester plusieurs solution, suivi plusieurs tuto ou démo de mise en place mais ça coince chez moi.
Environnement : NetBean 8.0.2 et Glassfish 4.1.13 pour application Maven JavaEE7, Primefaces 5.0

Afin de trouver la source du problème, j'ai réduite au minimum le code pour le reproduire, vous trouverez ici toutes les étapes. aucun autres fichiers n'a été modifié :



Etape 1: creation d'un projet Maven module EJB, galssfish 4.1, JavaEE7 'bugDeploiementEJB'

ITestBugEjb.java

package postbug.bugdeploiementejb;

public interface ITestBugEjb {
public String appelTestBugEjb();
}

ItestBugEjbLocal.java
package postbug.bugdeploiementejb;
import javax.ejb.Local;

@Local
public interface ITestBugEjbLocal extends ITestBugEjb {

}

IttestBugEjbRemote.java

package postbug.bugdeploiementejb;
import javax.ejb.Remote;
@Remote
public interface ITestBugEjbRemote extends ITestBugEjb {

}

testBugEjb.java


package postbug.bugdeploiementejb;
import java.io.Serializable;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
@Stateless (mappedName = "postbug.bugdeploiementejb")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class TestBugEjb implements ITestBugEjbLocal, ITestBugEjbRemote, Serializable {
@Override
public String appelTestBugEjb() {
return ("Hello World !");
}
}


Etape 2 : création d'un projet Maven Web application, Framework JSF/ PrimeFaces 5.0

Création d'un bean : 'BeanTestAppelEJB.java'

package postbug.bugappelejb;
import javax.annotation.PostConstruct;
import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
import postbug.bugdeploiementejb.ITestBugEjbLocal;
@ManagedBean
@ViewScoped
public class BeanTestAppelEJB {
private String monTexte;

@EJB (mappedName = "postbug.bugdeploiementejb")
private ITestBugEjbLocal texteEJB;

@PostConstruct
public void BeanTestAppelEJB() {
monTexte = texteEJB.appelTestBugEjb();
}
public String getMonTexte() {
return monTexte;
}
public void setMonTexte(String monTexte) {
this.monTexte = monTexte;
}

}


Modfication du code de la page : welcomePrimefaces.xhtml :

< p:layoutUnit position="center">
Welcome to PrimeFaces
<br/>
#{beanTestAppelEJB.monTexte}
</p:layoutUnit>

Etape 3 : test de la dépendance.
==> si j'ajoute la dépendance scope "compile", type "jar". Cela fonctionne OK

==> si je déploye l'EJB et que j'ajoute la dépendance scope "provided" et type "ejb", c'est là que ça ne fonctionne plus. Cf la log Glassfish à l'exécution de l'application Web (je ne pets pas tout pour le moment) :

Infos: visiting unvisited references
Infos: visiting unvisited references
Grave: Class [ Lpostbug/bugdeploiementejb/ITestBugEjbLocal; ] not found. Error while loading [ class postbug.bugappelejb.BeanTestAppelEJB ]
Infos: visiting unvisited references
Infos: visiting unvisited references
Infos: Initialisation de Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7@13362) pour le contexte «/bugAppelEJB2»
Grave: Critical error during deployment:
java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2570)
at java.lang.Class.getDeclaredFields(Class.java:1903)

Caused by: java.lang.ClassNotFoundException: postbug.bugdeploiementejb.ITestBugEjbLocal
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1783)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)
... 76 more

Grave: Startup of context /bugAppelEJB2 failed due to previous errors
Grave: Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:935)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6133)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)


Grave: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5954)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)

Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:280)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5394)

Caused by: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2570)

Avertissement: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)

Grave: Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)

Grave: Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)


Grave: Exception while loading the app
Grave: Undeployment failed for context /bugAppelEJB2
Grave: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lpostbug/bugdeploiementejb/ITestBugEjbLocal;


Pouvez-vous m'aider à trouver la raison de cette erreur ?
D'autre part, étant débutant, je profite de ce soucis pour vous demander comment savoir si deux application tourne sur une même JVM, et s'il faut utiliser l'interface "Local" ou plutôt "Remote" pour déclarer et utiliser un EJB ? Est-ce dans mon exemple le cas de l'interface Local est judicieuses ?
Encore merci de votre aide.


A votre disposition si besoin d'informations complémentaires.

[nathieb]

Bonjour,

Quand tu précises "provided", quand tu déploies c'est fournit par ton container exemple javaee,
si c'est ton propre package jar sous forme de client pour un package web type war, c'est toi qui doit le fournir.
Il faut donc regarder du côté maven pour ses scopes de déploiement.


Deuxième point si tu fais une applis dans le même container "jvm" alors local, sinon remote.
Dans ton cas local suffit. Si jamais tu passes a un client léger type swing il faudra effectivement implémenter du remote
comme interface.

Olivier

[bug007]

Bonjour nathieb et merci.

Bon j'ai suivi ta piste ce matin mais sans succès. J'avoue mon incompétence ....
J'ai bien vérifier le déploiement de mon jar en ejb sous glassfish

pom.xml
<groupId>PostBug</groupId>
<artifactId>bugDeploiementEJB</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>ejb</packaging>

<name>bugDeploiementEJB</name>

Résultat ok, visible dans la console du serveur:
Infos: visiting unvisited references
Infos: visiting unvisited references
Infos: Portable JNDI names for EJB TestBugEjb: [java:global/bugDeploiementEJB/TestBugEjb!postbug.bugdeploiementejb.ITestBugEjbRemote, java:global/bugDeploiementEJB/TestBugEjb!postbug.bugdeploiementejb.ITestBugEjbLocal]
Infos: Glassfish-specific (Non-portable) JNDI names for EJB TestBugEjb: [postbug.bugdeploiementejb, postbug.bugdeploiementejb#postbug.bugdeploiementejb.ITestBugEjbRemote]
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jms.injection.JMSCDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
Infos: bugDeploiementEJB was successfully deployed in 426 milliseconds.

J'ai tenter de changer les versions du pluging Maven, toujours le même résultat.
Une piste que je n'arrive pas à exploiter et de savoir pourquoi lors de l'exécution du war, il cherche la classe en locale : si j'ai bien compris la présence du 'L' devant le nom de la classe dans le libellé de l'erreur.
J'ai donc chercher au niveau du <addClasspath> mais toujours rien.
S'il y a un spécialiste Maven ? Ce qui me désole, c'est que l'utilisation de Maven est justement là pour simplifier ce fonctionnement ....
Si cela vous inspire d'autres pistes ou des idées de solution ? A vous lire, merci.

[nathieb]

Bonjour,

Il faut que tu postes tout ton pom.xml. j'ai l'impression que tu n'as pas rajouter une dépendance dans le war
sur le client EJB :

Exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
 
<dependencies> ...
 
<dependency>
            <groupId>opn.monpackage.ejb</groupId>
            <artifactId>monArtifactId</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <type>ejb</type>
            <scope>provided</scope>
...

Olivier

[bug007]

OK, je pense effectivement qu'il doit manquer quelque chose. Cependant l'utilisation de Maven doit réaliser automatiquement les ajouts. J'ai limiter au maximum des interventions manuels dans le cadre de mes recherches car les retours arrières sont fastidieux. Je n'ai pas trouvé ce qu'il manque dans les étapes à enchainer pour intégrer cet EJB dans le projet Web. peut-être une autre dépendance ?
Voici en pièce jointe les pom.xml : du projet EJB ainsi que celui du projet Web (dans sa version souhaité : Provided/ejb).
Merci de le relecture des fichiers.pom-EJB.zip

[nathieb]

Bonjour,

Il faut que cela soit en mode compile en terme de dépendance dans le pom.xml du war.
En fait, tu embarques une copie jar du package, "client" de l"EJB".

http://www.adam-bien.com/roller/abie...va_ee_6_ejb_31 pour ma part, j'utilise encore des EAR.
car dans ton cas, ce sont des EJB lites. si je ne me trompe pas ?

Olivier

[bug007]

Bonjour,

Merci Olivier pour tes retours.
Effectivement dans le cas d'une intégration de la dépendance en jar, scope: compile, cela fonctionne. C'est bien mon propos à l'origine du post. C'est d'ailleur de cette façon que je continue à avancer sur le projet en attendant une solution. (mon exemple a été volontairement réduit pour reproduire mon soucis, en vérité j'ai un gros EJB métier + persistance vers BDD ... que je souhaites partager à plusieurs applications web et client ...)
En revanche, cela ne correspond pas à un mode d'architecture qui devrait permettre de faire vivre l'EJB indépendamment. Cf les 2 derniers commentaires postés sur le lien "Adam..." (merci pour cette trouvaille). En effet dans son exemple concret il embarque de façon encapsulé les différents jar contenant les sources java (exemple datant de 2009).
j'ai donc fait le test ce matin. Si mon EJB a été déployé au préalable de façon indépendante avant l'exécution de mon application web (war contenant le jar) alors il existe un problème de conflit au niveau glassfish :
Grave: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error

Il faut donc désactiver l'EJB avant de pouvoir déployer l'application Web ! Je n'ai pas encore fait le test de déployer deux applications web utilisant les mêmes dépendances jar ...(A Suivre)

D'après ma compréhension ( à confirmer), cela ne correspond pas aux attentes que l'on peut avoir d'un composant EJB. Surtout s'il contient des éléments de persistance : connection à une BD ... En effet, celui-ci doit pouvoir rester disponible pour plusieurs applications web, il doit aussi pouvoir suivre sa vie sans nécessiter le redéploiement de toutes les applications web qui l'utilisent ? ou pour permettre plusieurs version et donc une gestion de configuration propre au composant.
Si je souhaites découper le fonctionnement des applications en partageant une ressource jar sous la forme d'EJB comment dois-je alors procéder ?
J'ai peut-être omis une étape dans les phases de mise en place ?
Sinon, l'utilisation de EAR ne change pas la donne à mon avis( a confirmer), puisque le besoin sera toujours de pouvoir relier un EJB (déjà déployer) avec un war (application web utilisant cet EJB) ou autres applications.
Merci d'avance de vos retours.

[nathieb]

Bonjour,

Un début de réponse ...
http://piotrnowicki.com/2012/11/comm...cation-server/

J'ai pris le temps de lire le lien, il ressort qu'il faut de toute façon utiliser les remote à partir du moment que
tu packages dans deux ejb, jar ou ear ton appli.

le Local fonctionne correctement que ce sont des modules packagés ensembles.

Olivier

[bug007]

Bonsoir,

Je suis d'accord avec ton propos, il semble qu'il vaut mieux tabler directement sur du Remote qui fonctionne a priori dans tous les cas. La différence entre JNDI et EJB n'est apparemment pas si évidente et l'utilisation du 'name' ou 'mappedName' semble en tenir compte. Il semble exister une équivalence que j'ai trouver sur un tuto du club "développez". Sinon, j'ai potassé le lien suivant et fait encore différents tests, toujours sans succès : http://docs.oracle.com/cd/E26576_01/...htm#GSDVG00520

Je sature pour ce soir car je ne trouve aucune piste qui fonctionne et il faut aussi que j'avance sur le reste ....
Pour donner quelques résultats de mes recherches et ouvrir de nouvelles pistes pour votre aide, voici en vrac quelques éléments.

D'abord, voici un exemple qui montre la facilité avec laquelle nous devrions pouvoir mettre ce genre de chose en place (sur du stand alone, mais le principe est bien posé !): https://glassfish.java.net/javaee5/e...les/Sless.html
Ensuite, avec l'aide des liens d'Olivier, j'ai pu trouver d'autres posts du même type mais qui ne m'ont pas permis d'avancer (pas très sympas de ma part de boucler sur le sujet plutôt que d'apporter la solution, mais avec l'aide de ... peut-être la lumière jaillira) :
https://www.java.net/forum/topic/gla...-jar-classpath
https://www.java.net/forum/topic/gla...assfish-server

Pour reprendre ce qui ressort de l'article de Piotr : " but I would expect to have something very similar to the JBoss Modules !!". Quelqu'un connait l'équivalence de JBoss Modules pour Glassfish ? et comment faire pour le mettre en place ?

Dernier espoir, avez-vous déjà partager un projet Jar via ses interfaces sur plusieurs autres projets ? Si oui, quelles sont les étapes que j'ai raté dans mon exemple ?
A bientôt de vous lire ....