Impossible d'accéder à un bean enterprise à partir d'un servlet, d'un fichier JSP, d'un programme autonome ou d'un autre client

Utilisez les conseils ci-dessous pour l'identification et la résolution des problèmes liés à l'accès aux beans enterprise.

[AIX Solaris HP-UX Linux Windows][IBM i]Si le client est éloigné du bean enterprise, c'est-à-dire qu'il s'exécute sur un autre serveur d'applications ou en tant que client autonome, parcourez les journaux de la machine JVM du serveur d'applications qui héberge le bean enterprise, ainsi que les fichiers journaux du client.

[z/OS]Si le client est éloigné du bean enterprise, c'est-à-dire qu'il s'exécute sur un autre serveur d'applications ou en tant que client autonome, parcourez les journaux du serveur d'applications qui héberge le bean enterprise, ainsi que les fichiers journaux du client.

[AIX Solaris HP-UX Linux Windows][IBM i]Si vous ne trouvez pas d'incident similaire au vôtre, ou si les informations fournies ne permettent pas de résoudre votre incident, effectuez les opérations ci-dessous :
  1. Si l'incident semble lié au service annuaire, c'est-à-dire si une exception NameNotFoundException ou un ID de message commençant par NMSV s'affiche, reportez-vous aux rubriques suivantes pour plus d'informations :
  2. Vérifiez s'il est identifié et documenté en utilisant les liens de la rubrique Diagnostics et résolution des problèmes : Ressources d'apprentissage.
Si vous ne parvenez toujours pas à résoudre l'incident, contactezIdentification des incidents dans l'aide d'IBM.

java.lang.NoSuchMethodError

Lors de la tentative d'appel d'une méthode sur un bean session, une erreur java.lang.NoSuchMethodError s'est produite.

Ce type d'erreur est illustré dans l'exemple suivant :
Lors de la tentative d'appel de la méthode xSLTStory4Session sur un bean, une erreur java.lang.NoSuchMethodError s'affiche.

CNTR0020E: EJB a renvoyé une exception inattendue (non déclarée) lors de l'appel de la méthode "xSLTStory4Session" sur le bean "BeanId(ERWW_v8#XSLTStory4SessionEJB3.jar#XSLTStory4SessionFacadeBean, null)". 
Données d'exception : java.lang.NoSuchMethodError: paysession/ejb3/PaySessionFacadeRemote.paySession(Ljava/lang/String;)Ljava/lang/String;

Dans ce cas, il existe plusieurs versions de l'interface PaySessionFacadeRemote dans plusieurs modules au sein du fichier EAR. L'une des interfaces ne contient pas la méthode attendue.

La classe de raccord a été générée par l'exécution à partir de la première version de l'interface PaySessionFacadeRemote dans le chemin d'accès aux classes du fichier EAR qui était la version incorrecte.

Exception ObjectNotFoundException uObjectNotFoundLocalException lors de l'accès à un EJB avec état

L'erreur peut provenir du fait qu'un bean de session avec état ayant dépassé le délai d'attente octroyé a été supprimé par le conteneur. Cet événement doit être codé, selon la spécification EJB 2.1 et version ultérieure.

Trace de pile commençant par "La méthode EJSContainer E Bean a envoyée l'exception [nom_exception]" détectée dans le fichier journal JVM

Si le nom de l'exception indique une exception émise par une classe IBM commençant par "com.ibm...", recherchez alors le nom de l'exception dans le centre de documentation et dans l'aide en ligne. Si "nom_exception" désigne une exception envoyée par votre application, prenez contact avec le développeur de l'application afin de déterminer la cause de l'incident.

javax.naming.NameNotFoundException : Nom introuvable dans le contexte de message "local"

Cette erreur peut provenir du fait que le bean enterprise n'est pas local (ne s'exécute pas sur la même machine virtuelle Java ou serveur d'applications) pour le client JSP, le servlet, l'application Java ou un autre bean enterprise, alors que l'appel s'adresse à l'une des méthodes de l'interface "locale" du bean enterprise. Si l'accès fonctionne dans un environnement de développement mais pas après déploiement sur WebSphere Application Server, par exemple, il est possible que le bean enterprise et son client aient été sur la même JVM lors du développement mais qu'après déploiement ils se trouvent dans des processus séparés.

Pour résoudre cet incident, prenez contact avec le développeur du bean enterprise et déterminez si l'appel du client s'adresse à une méthode de l'interface locale du bean enterprise. Si tel est le cas, modifiez le code client de façon à appeler une méthode d'interface éloignée ou favorisez la méthode locale au sein de l'interface éloignée.

Les références aux beans enterprise des interfaces locales sont liées dans un espace de nom local du processus de serveur avec le schéma d'URL local. [AIX Solaris HP-UX Linux Windows][IBM i]Pour obtenir un vidage d'un espace de nom local d'un serveur, exécutez l'utilitaire de vidage d'espace de nom décrit dans la rubrique "Utilitaire de clichage d'espace de nom pour les espaces de nom java:, local: et server".

Envoi de l'exception BeanNotReentrantException

Cet incident peut survenir lorsqu'un code client, en général un servlet ou un fichier JSP, tente d'appeler le même bean de session avec état à partir de deux unités d'exécution de client différentes. Cette situation se produit souvent lorsqu'une application stocke la référence au bean de session avec état dans une variable statique, utilise une variable JSP globale (statique) pour faire référence au bean de session avec état ou stocke la référence au bean de session avec état dans l'objet session HTTP. L'application fait alors en sorte que le navigateur du client envoie une nouvelle requête au servlet ou au fichier JSP avant que la requête précédente ne soit terminée.

Pour résoudre cet incident, demandez au développeur du code client de revoir le code de ces conditions.

Envoi de l'exception CSITransactionRolledbackException / TransactionRolledbackException

[AIX Solaris HP-UX Linux Windows][IBM i]Un conteneur de bean enterprise crée ces exceptions de haut niveau pour indiquer qu'un appel de bean enterprise n'a pas abouti. Lorsque cette exception est envoyée, parcourez les journaux de la machine JVM pour en déterminer la cause.

[z/OS]Un conteneur de bean enterprise crée ces exceptions de haut niveau pour indiquer qu'un appel de bean enterprise n'a pas abouti. Lorsque cette exception est envoyée, parcourez les journaux pour en déterminer la cause.

Les causes possibles sont les suivantes :
  • Le bean enterprise peut envoyer une exception non déclarée comme élément de sa signature de méthode. Le conteneur est nécessaire pour annuler alors la transaction. Cet incident se produit généralement lorsque le bean enterprise ou le code qu'il appelle crée une exception NullPointerException, ArrayIndexOutOfBoundsException ou autre exception d'exécution Java ou lorsqu'un bean BMP est confronté à une erreur JDBC. La meilleure solution consiste à passer en revue le code du bean enterprise et à rectifier la cause de l'exception sous-jacente ou à ajouter l'exception à la signature de la méthode de l'incident.
  • Il est possible qu'une transaction tente d'effectuer un travail supplémentaire une fois déclarée annulée "Marked Rollback", en cours d'annulation "RollingBack" ou annulée "RolledBack". Une transaction ne peut effectuer aucun autre travail une fois passée à l'un de ces états. Cet incident se produit souvent parce que la transaction est en dépassement de délai, situation souvent liée à un blocage de la base de données. Faîtes appel aux outils de gestion de base de données de l'application ou à l'administrateur pour déterminer si les transactions de base de données appelées par le bean enterprise sont en dépassement de délai.
  • La validation d'une transaction peut échouer pour cause de travail en suspens des transactions locales. La transaction locale détecte un "travail en suspens" lors de la validation. L'action par défaut appliquée à une transaction locale confrontée à une "action non résolue" est "annuler". Vous pouvez la remplacer par "valider" dans un outil d'assemblage.

Echec de la tentative de démarrage du module EJB avec l'exception "javax.naming.NameNotFoundException dataSourceName_CMP"

Cet incident se produit dans l'un des cas suivants :
  • Lors de la configuration de la ressource source de données, l'option Persistance gérée par conteneur n'a pas été sélectionnée.
    • Pour confirmer qu'il s'agit bien de l'incident, dans la console d'administration, parcourez les propriétés de la source de données indiquée dans NameNotFoundException. Dans le panneau de configuration, recherchez une case intitulée Persistance gérée par conteneur.
    • Pour résoudre cet incident, cochez la case Persistance gérée par conteneur.
  • Si l'option de persistance gérée par conteneur est sélectionnée, il est possible que la source de données CMP n'ait pas été liée dans l'espace de nom.
    • [AIX Solaris HP-UX Linux Windows][IBM i]Recherchez d'autres erreurs ou avertissements liés aux noms dans la barre d'état et dans les journaux JVM du serveur d'applications d'hébergement. Pour rechercher les autres incidents liés aux noms, voir Incidents liés à l'accès aux applications.
    • [z/OS]Recherchez d'autres erreurs ou avertissements liés aux noms dans la barre d'état et dans les journaux du serveur d'applications d'hébergement. Pour rechercher les autres incidents liés aux noms, voir Incidents liés à l'accès aux applications.
[AIX Solaris HP-UX Linux Windows][IBM i]

La transaction [ID tran] a dépassé son délai d'attente de 120 secondes lors de l'accès à un bean enterprise

Cette erreur peut se produire lorsqu'un client exécute une transaction sur un bean enterprise CMP ou BMP.
  • La valeur de dépassement de délai par défaut des transactions de bean enterprise est de 120 secondes. Une fois ce délai écoulé, la transaction expire et la connexion se ferme.
  • Si la transaction prend légitimement plus de temps que le délai indiqué, accédez à gestion des serveurs d'applications nom_serveur, sélectionnez la page Propriétés du service de transaction et examinez la propriété Dépassement du délai autorisé pour la durée de vie des transactions. Augmentez au besoin la valeur de cette propriété et sauvegardez la configuration.
[z/OS]

Génération du message BBOT0003W

Le message BBOT0003W indique un délai d'expiration de la transaction. Le délai d'expiration peut se traduire par un arrêt anormal de l'objet servant sur lequel la transaction est exécutée.
  • La valeur de dépassement de délai par défaut des transactions de bean enterprise est de 120 secondes. Une fois ce délai écoulé, la transaction expire et la connexion se ferme.
  • Si la transaction dure normalement plus longtemps que le délai d'expiration spécifié, sur la console d'administration, procédez comme suit :
    1. Accédez à Gestion des serveurs d'applications > nom_serveur
    2. Sélectionnez la page Propriétés du service des transactions
    3. Augmentez la valeur du paramètre Dépassement du délai autorisé pour la durée de vie des transactions
    4. Sauvegardez la configuration.
    Remarque : z/OS utilise la valeur que vous avez définie pour le paramètre Dépassement du délai autorisé pour la durée de vie des transactions comme paramètre par défaut du délai d'expiration des transactions. Si vous définissez pour cette propriété une valeur supérieure au délai d'expiration maximal des transactions, z/OS utilise ce délai comme valeur par défaut.

Symptôme :CNTR0001W : Un bean session avec état n'a pas pu être passivé

Cette erreur peut se produire lorsqu'un objet Connexion utilisé dans le bean n'est pas fermé ou annulé.

[AIX Solaris HP-UX Linux Windows][IBM i]Pour confirmer qu'il s'agit bien de la source de l'incident, recherchez dans le journal de la machine JVM du conteneur d'EJB qui héberge le bean enterprise une pile d'exceptions similaire à la suivante :
[time EDT] <ThreadID> StatefulPassi W CNTR0001W: 
Un bean session avec état n'a pas pu être passivé : StatefulBeanO
(BeanId(XXX#YYY.jar#ZZZZ, <ThreadID>), 
state = PASSIVATING) com.ibm.ejs.container.passivator.StatefulPassivator@<ThreadID>
java.io.NotSerializableException: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection 
 at java.io.ObjectOutputStream.outputObject((Code compilé)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Code compilé)) 
 at java.io.ObjectOutputStream.outputClassFields((Code compilé)) 
 at java.io.ObjectOutputStream.defaultWriteObject((Code compilé)) 
 at java.io.ObjectOutputStream.outputObject((Code compilé)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Code compilé)) 
 at com.ibm.ejs.container.passivator.StatefulPassivator.passivate((Code compilé)) 

 at com.ibm.ejs.container.StatefulBeanO.passivate((Code compilé) 
 at com.ibm.ejs.container.activator.StatefulASActivationStrategy.atUnitOfWorkEnd
                      ((Code compilé)) 
 at com.ibm.ejs.container.activator.Activator.unitOfWorkEnd((Code compilé)) 
 at com.ibm.ejs.container.ContainerAS.afterCompletion((Code compilé)
XXX,YYY,ZZZ est le nom du bean, et <IDUnitéExécution> l'unité d'exécution de cette passe.
[z/OS]Pour confirmer qu'il s'agit bien de la source de l'incident, recherchez dans les journaux du conteneur d'EJB qui héberge le bean enterprise une pile d'exceptions similaire à la suivante :
StatefulPassi W CNTR0001W : 
Un bean session avec état n'a pas pu être passivé : StatefulBeanO
(BeanId(XXX#YYY.jar#ZZZZ), 
state = PASSIVATING) 
java.io.NotSerializableException: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection 
 at java.io.ObjectOutputStream.outputObject((Code compilé)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Code compilé)) 
 at java.io.ObjectOutputStream.outputClassFields((Code compilé)) 
 at java.io.ObjectOutputStream.defaultWriteObject((Code compilé)) 
 at java.io.ObjectOutputStream.outputObject((Code compilé)) 
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Code compilé)) 
 at com.ibm.ejs.container.passivator.StatefulPassivator.passivate((Code compilé)) 

 at com.ibm.ejs.container.StatefulBeanO.passivate((Code compilé) 
 at com.ibm.ejs.container.activator.StatefulASActivationStrategy.atUnitOfWorkEnd
                      ((Code compilé)) 
 at com.ibm.ejs.container.activator.Activator.unitOfWorkEnd((Code compilé)) 
 at com.ibm.ejs.container.ContainerAS.afterCompletion((Code compilé)
XXX,YYY,ZZZ est le nom du bean.

Pour résoudre cet incident, l'application doit fermer toutes les connexions et attribuer la valeur null à toutes les références des connexions. Cette opération s'effectue généralement dans la méthode ejbPassivate() du bean. Notez également que le bean doit avoir un code pour se réapproprier ces connexions à la réactivation du bean. Sinon, des exceptions NullPointerExceptions sont renvoyées lorsque l'application tente de réutiliser les connexions.

[AIX Solaris HP-UX Linux Windows][IBM i]

Symptôme : org.omg.CORBA.BAD_PARAM : L'objet servant n'est pas du type attendu. Code mineur : 4942F21E Terminé : Non

Cette erreur peut être renvoyée à un programme client lorsque celui-ci tente d'exécuter une méthode EJB.

Généralement, cette erreur est due à une incohérence entre la définition de l'interface et l'implémentation des installations client et serveur.

Une autre cause possible est l'utilisation d'un serveur d'applications configuré pour faire appel à une procédure de chargement de classes unique. Si une application est désinstallée alors que le serveur d'applications est actif, les classes de l'application désinstallée restent chargées sur le serveur. Si vous changez l'application et que vous la redéployez et réinstallez sur le serveur d'applications, les classes précédemment chargées correspondent à un niveau antérieur. Les classes de niveau antérieur entraînent une incohérence entre les versions du code stocké sur le client et le serveur.

Pour résoudre le problème, procédez comme suit :
  1. Remplacez le schéma de chargement des classes du serveur d'applications par multiple.
  2. Arrêtez et redémarrez le serveur d'applications et faites une nouvelle tentative.
  3. Assurez-vous que les versions du code client et serveur sont identiques.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_ejbaccessprobs
Nom du fichier : rtrb_ejbaccessprobs.html