dans WebSphere 6.1 J'ai créé une source de données à une instance Oracle 11g à l'aide du client mince JDBC.
dans Oracle, j'ai deux utilisateurs, un existant et un autre nouvellement créé.
My WebSphere Datasource est OK Si j'utilise l'alias d'authentification géré par le composant de l'utilisateur existant, mais échoue avec le message "Invalid utilisateur / Mot de passe" si j'utilise l'alias du nouvel utilisateur. Le message d'erreur est: Il n'y a rien dans les journaux JVM. J'ai greppé toutes les journaux WebSphere et ils ne mentionnent pas de ma connexion du tout. Je peux confirmer que le nom d'utilisateur et le mot de passe sont corrects en vous connectant via SQLPlus ou (pour prouver que la connexion JDBC est OK) via Squirrel . J'ai vérifié à Oracle que le nouvel utilisateur dispose de tout le système Privs que l'utilisateur existant a. Toute réflexion sur ce qui se passe ou comment je peux déboguer cela plus loin?
6 Réponses :
Si cela arrive à quelqu'un d'autre, j'ai redémarré WebSphere et tous mes problèmes sont partis. C'est un véritable voyageur de logiciels de qualité.
Si vous modifiez la configuration intégrée (vous faites cela, car vous modifiez les informations d'identification d'un alias JAAS), vous êtes susceptible d'avoir un redémarrage du serveur pour qu'il prenne effet.
@Manglu qui dépend de la portée du changement de configuration et de la portée dans laquelle vous souhaitez les modifications visibles. Si vous avez changé quelque chose au niveau de la cellule, mais que vous êtes intéressé uniquement par voir les modifications immédiatement sur deux instances de serveur, il n'y a aucune raison de recycler toute la topologie. Cette distinction peut ne pas être importante dans les environnements de non-production, mais en production.
Oftentimes quand les gens me disent qu'ils ne peuvent pas se connecter à Oracle 11g avec le mot de passe correct, je sais qu'ils ont été pris par des mots de passe devenant sensibles à la casse entre 10 g et 11g.
Nan! N'oubliez pas que Oracle revient dans la journée lorsque vous ne pouviez même pas supposer que votre client serait capable de mélanger. Même en 11g, il est facultatif.
juste fyi. Je suppose que vous exécutez WebSphere en mode de déploiement de réseau. Ce comportement que vous rencontrez est en réalité par design.
La raison en est que la touche "Connexion de test" que vous voyez sur la console d'administration, invoque le test de connexion JDBC à partir du processus de l'agent Node . Il n'ya aucun moyen pour les informations d'alias J2C de propager à l'agent de nœud sans le redémarrer; Certains objets de configuration prennent effet dans WebSphere dès que vous enregistrez la configuration sur le référentiel principal, et certains prennent effet uniquement sur un redémarrage. Les alias J2C prennent effet sur les redémarrages.
Dans une topologie de déploiement de réseau, vous pouvez avoir un nombre d'instances de serveur contrôlé par le même agent de nœud. Vous pouvez redémarrer vos instances de serveur comme vous le souhaitez, mais sauf si vous redémarrez l'agent de nœud lui-même, le bouton "Connexion de test" ne fonctionnera jamais.
C'est une limitation de WebSphere connue ... qui existe également la version 7.0, alors ne soyez pas surpris lorsque vous le testez pendant votre prochaine migration. : -)
Cela a vraiment résolu mon problème que j'étais coincé depuis la nuit dernière. Mais lorsque je modifie le mot de passe dans la section Données d'authentification J2C, cliquez sur OK / Appliquer, il rafraîchit l'ancien mot de passe et la connexion échoue à nouveau. J'ai fait un redémarrage du nœud et de la DM et de poster que cela fonctionne bien maintenant. À votre santé.
Essayez ceci: Source de données Définition Sécurité Utilisez l'alias J2C à la fois une autocollante gérée par le composant et la contribution automatique gérée par conteneur
J'ai pointu ma source de données à une authentification gérée par le composant ainsi que l'authentification gérée par le conteneur.Il fonctionne bien maintenant ........
Si vous créez ou mettez à jour une source de données qui pointe vers un alias de données d'authentification J2C nouvellement créé, Après avoir redémarré le gestionnaire de déploiement, les données d'authentification J2C sont reflétées dans la configuration d'exécution. Toute modification des champs de données d'authentification J2C nécessite un redémarrage du gestionnaire de déploiement pour que les modifications prennent effet.