Discussion :

[Alkhan]

Bonjour,

j'ai un problème avec glassfish. Dans mon environnement eclipse (et j'ai aussi testé avec netbeans pour être sur) lorsque je fais un publish je me retrouve avec des classes qui, a mon sens, ne sont pas valide.

en fait, j'ai vérifié en mode debug et je me retrouve dans le cas suivant (qui pour moi ne devrait pas se produire) :

1 - J'ai une classe TypeUtilisateur, et un bean singleton qui charge les types utilisateur dans une liste.
3 - j'ai une JSF qui affiche la liste des types
3 - J'ai une methode (getAsString de Converter), qui est appeler par l'objet primefaces, qui prend en paramètre un Object qui dans ce cas précis doit être une instance de TypeUtilisateur.

Jusque la, cela parait plutôt normal, sauf que lorsque je fais un publish à partir de mon environnement, ensuite si je fait un instanceof entre la variable et TypeUtilisateur, la réponse est false.

petite précision pour ceux qui en douterait l'objet passé en paramètre est bien une instance de la classe TypeUtilisateur.
Alors pourquoi false ? la réponse est simple la définition de la classe de l'objet est dans un classLoader différent de celui de TypeUtilisateur.class.

Mon problème est que dès que je modifie une classe java le déploiement échoue, je perd un temps fou a relancer le serveur d'applications.
Quelqu'un peux t'il me dire s'il est possible de changer un élément de configuration du serveur pour éviter cela, ou même une autre solution ?

Merci d'avance !


Environnement :
glassfish 4
EclipseLink 2.5
JSF 2
primefaces 3.5
Eclipse 4.2

[tchize_]

La webapp redémarre bien à chaque publish, ou tu utilise un autre mécanisme de glassfish pour ne recharger que les classes qui ont changé? Dans le deuxième cas, ce genre de mécanisme crée un ClassLoader qui charge ces nouvelle classe et, si t'as gardé d'anciennes instances, elles ne sont pas mises à jour, d'où le problème.

Ce qui m'étonne, c'est que la dernière fois que j'ai eu ce genr de problème, c'était il y a 8 ans, avec le "vulturing" de Novell eXtend


Ma suggestion: désactive le publish automatique, et fait un publish manuel.

[Alkhan]

Merci pour ta réponse !

Pour ce qui est du publish c'est moi qui le déclanche, il n'est pas automatique !
Dans la vue server (dans eclipse) il indique simplement qu'il faut faire un publish mais il ne le fait pas tout seul.

Pour ce qui est de glassfish j'ai fait une installation sans changer la configuration de base.

Concernant le classLoader effectivement j'ai bien deux webappClassLoader, mais si c'est un problème de config, je veux bien savoir ce que je dois changer

[tchize_]

quand tu fais un publish, ta webapp redémarre bien?

[fxrobin]

Bonjour, et il est de quel type l'objet quand tu fais un "getClass().toString()" ?
Le ManagedBean associé à ta page JSF ne serait-elle pas en Scope Session ou View ? et donc avec un redéploiement "à chaud", JSF perdrait l'arbre de composant de la page puisque le serveur d'application a ré-initialisé l'application, sans pour autant réinitialiser la session.

Tu peux déjà tester en faisant une modif à chaud et en fermant ton navigateur complètement et d'en ouvrir un autre, histoire d'avoir une nouvelle session et donc confirmer ou infirmer mon hypothèse.

en fait, je pense que ton instanceof renvoie "false" car ton objet est "null" puisque la vue n'a pas pu être restaurée.

Peux-tu montrer le code de ton converter.

Bon courage.

[Alkhan]

quand tu fais un publish, ta webapp redémarre bien?

il semblerait que oui.
la trace lors du publish :

2013-09-05T09:29:31.048+0200|INFO: visiting unvisited references
... // la ligne ci dessus est plusieurs fois
2013-09-05T09:29:31.204+0200|INFO: EJB5181ortable JNDI names for EJB UserTypeEjb: [java:global/MonApp/UserTypeEjb!com.monapp.user.UserTypeEjb, java:global/MonApp/UserTypeEjb]
.... // ici se trouve les nom JNDI de tous les autres EJB (comme celui juste au dessus)
2013-09-05T09:29:31.423+0200|INFO: Adding singleton for WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
2013-09-05T09:29:33.251+0200|INFO: Registering WebSocket filter for url pattern /*
2013-09-05T09:29:33.267+0200|INFO: Initialisation de Mojarra 2.2.0 ( 20130502-2118 https://svn.java.net/svn/mojarra~svn/tags/2.2.0@11930) pour le contexte «/MonApp»
2013-09-05T09:29:33.454+0200|WARNING: WELD-001529 An InjectionTarget implementation is created for a class org.omnifaces.context.OmniPartialViewContextFactory which does not have any appropriate constructor.
2013-09-05T09:29:33.470+0200|WARNING: WELD-001529 An InjectionTarget implementation is created for a class org.primefaces.context.PrimePartialViewContextFactory which does not have any appropriate constructor.
2013-09-05T09:29:34.001+0200|INFO: Running on PrimeFaces 3.5
2013-09-05T09:29:34.001+0200|INFO: Using OmniFaces version 1.5
2013-09-05T09:29:34.048+0200|INFO: Loading application [MonApp] at [/MonApp]
2013-09-05T09:29:34.095+0200|INFO: MonApp a été déployé en 4*625 ms.

en fait, je pense que ton instanceof renvoie "false" car ton objet est "null" puisque la vue n'a pas pu être restaurée.

Non je n'est rien de null, mais bien deux classLoader différent.


J'ai continué mes recherches sur le net et j'ai trouvé des choses plutôt inquiétantes !
Il semblerait que le cache de EclipseLink ne soit pas remis a zéro lors du re-deploiement , ce qui explique que j'ai ce problème que sur les Entités et pas sur d'autres objets.
Je vais donc tenter un autre provider pour voir si le problème persiste !

N'hesitez surtout pas si vous avez d'autres suggestions, je reviendrais afin d'indiquer le résultat du test.

Merci a vous deux

[Alkhan]

bon je suis dedans jusqu'au cou , j'ai voulu essayer hibernate comme provider .... d'une je suis en JPA 2.1 donc les versions en dessous de la 4.3 ne fonctionne pas. J'ai tenté de passer en JPA 2.0 et sa crash, j'ai même tenté hibernate 4.3beta et crash aussi !

J'ai déja suffisement de problèmes, je vais pas m'en mettre un autre, donc je reste avec EclipseLink, au moins je sais qu'en redémarrant le domaine ca marche !

Si quelqu'un à une autre idée c'est pas de refus !!

merci d'avance

[tchize_]

Désactiver le cache de EclipseLink ?

[fxrobin]

Tu veux pas montrer le code source de ton singleton, de ton converter, de ton ManagedBean et de ta page JSF ... car c'est très étrange ce que tu décris.

Je travaille tous les jours sous l'environnement que tu décris (Version GlassFish 3.1) et je n'ai aucun problème de republish.

tu peux aussi montrer le fichier de conf de glassfish (celui de ton EAR)

as-tu essayé avec "delegate=false" pour la conf du classloader ?

[Alkhan]

bonjour,
Je répond un peu tard, mais je voulais attendre pour être sur d'avoir résolu le problème.

Mon problème venait d'une option coché (dans eclipse) sur les propriétés du serveur.
Cette option est : Preserve sessions across redeployment

comme on peux le comprendre avec le nom de cette option, des choses restaient entre chaque déploiement et provoquait les effets de bord que j'ai décrit.

Maintenant tout est rentré dans l'ordre !

Merci a vous deux !

[fxrobin]

C'était donc bien un problème de session, comme je l'avais suggéré

JSF perdrait l'arbre de composant de la page puisque le serveur d'application a ré-initialisé l'application, sans pour autant réinitialiser la session.