J'ai Eclipse Indigo que j'utilise pour développer un projet JSF 2 à l'aide de Glassfish 3 Open Source, celle-ci dans mon ordinateur alors dans mon instance EC2 également, à Amazon Aws, pour les deux Glassfish, j'ai créé un pool de connexion JDBC à utiliser avec mon JPA Entity Manager.
localement, mon projet fonctionne assez bien, mais lorsque je déploie le projet et essayez d'exécuter le même formulaire, ce qui obtient certaines valeurs de la base de données qui exécute dans la même instance EC2 qui exécute le poisson de verre dur. P>
Je reçois ce message: p>
Je cherche à ce sujet, mais je n'ai rien trouvé jusqu'à présent. P> Il y a une certaine configuration que je devais faire pour cela fonctionne? P> Voici le StackTrace: P> 
P> @Stateless(mappedName = "logEAO")
@LocalBean
public class LogEAO {
@PersistenceContext
private EntityManager em;
public LogEAO() {}
public Log find(int id) {
return em.find(Log.class, id);
}
// ..
3 Réponses :
de votre stacktrace:
causée par: java.lang.illegalStateException: tenter d'exécuter une opération sur une entité ferméeManagerFactory.
Votre code EJB semble bien. Il s'agit plus probablement d'un virus de verre de verre ou d'une mauvaise configuration:
- Assurez-vous que votre configuration de DataSource JTA a raison
- Assurez-vous que vous " en utilisant une version de gishfish qui n'a pas de bogue de redéploiement
- Ce bogue de redéploiement est corrigé en 3.1.2 et 4.0
Cela ne peut signifier que vous devez gérer manuellement leentitymanagerfactory (etEntityManager ) au lieu de laisser le conteneur faire le travail par juste@ PersistaceContext .Le
EntityManagerFactory est intimé à créer une seule fois sur le démarrage de WebApp, réutilisé dans toute la vie de WebApp et fermé sur l'arrêt de WebApp. Il ne doit pas être fermé quelque part à mi-chemin ou être sérialisé et réutilisé pour un prochain cycle de redémarrage.Puisque vous ciblez apparemment Glassfish, je recommande fortement de ne pas gérer vous-même, mais laisser Glassfish faire le travail. Vous vous retrouvez avec code EJB beaucoup plus simple, sans tous les tracas de gérer manuellement les transactions.
Voir aussi:
J'ai vu votre lien et la seule différence de comparaison avec l'exemple que vous indiquez est que @Localbean doit-il le supprimer?
Attendez, selon l'extrait de code EJB dans votre mise à jour de la question, vous n'obtenez pas manuellement le entitymanager , mais simplement en utilisant @Persiscecontext pour que le conteneur soit injecté. Donc, vous le faites de bonne manière. C'est peut-être un bug ou une mauvaise configuration de poisson-verre. Avez-vous un contrôle administrateur complet dessus? Êtes-vous sûr que la configuration JTA DataSource en persistance.xml et la console d'administration Glassfish est 100% d'accord?
J'ai le contrôle administrateur complet de Glassfish, je pense à la supprimer et à tout recommencer. Le JTA DataSource, tout va bien parce que j'ai fait le ping et cela me montre que tout allait bien. La même chose pour la persistance.xml.
Il suffit de redémarrer le poisson de verre manuellement l'a fait. Merci pour les astuces. On dirait que ma version avait ce bug.
J'ai eu ce problème et j'ai trouvé une solution.
Le problème est que Eclipse (avec le plug-in Glassfish) commence / n'arrête que le domaine et non la base de données. P>
Étapes: P>
Détails: P>
I Eclipse - Cela a arrêté le serveur de poisson-verre. Puis arrêtez la machine - arrêtez la base de données. Sur Redémarrez, Ouvrez Eclipse, a commencé Server et essayé de déployer la même application. Échec avec l'erreur: P>
java.lang.IllegalStateException: Attempting to execute an operation on a closed EntityManagerFactory
Si vous utilisez Glassfish Server, redémarrez le serveur le faisait pour moi.
travaillé pour moi - essayez-le, surtout après un refacteur massif
Cette alerte est typique pour Mojarra (avec la scène de projet définie sur
Développement ) Lors de l'envoi d'une demande AJAX aboutit à une exception lors de l'invoque Action. Vous pouvez trouver la structure complète dans le journal du serveur. Ou, (temporairement) désactiver de sorte que vous obtenez la page d'erreur HTTP 500 dans son intégralité. Pour une meilleure manipulation d'exception des demandes Ajax, cochez Ce . Une fois que vous avez la structure complète, incluez-la dans votre question. Ensuite, nous pouvons expliquer la cause et propulsez la solution basée sur la stacktrace. @Ballusc vous avez raison ma scène de projet est définie sur le développement, devriez-le supprimer? J'ai eu le journal de Glassfish comme tu m'as dit, voici dans ma post-mise à jour.
Non Si vous le supprimez, vous n'obtiendrez plus cette alerte afin que vous n'obtiens plus notification que quelque chose a échoué pendant la demande d'Ajax. Cela ne résout pas le problème sous-jacent.
Que se passe-t-il si vous arrêtez et commencez Glassfish. Après avoir commencé, essayez à nouveau votre site, j'ai passé beaucoup de temps avec des problèmes comme celui-ci. Il y a un bug dans Glassfish 3.1 sur le ré-déploiement.