Erreur de classe DCH avec JavaMail

La probablité est élevée que si vous travaillez sur le serveur KARAF (OSGI), les suggestions ci-dessus seront difficiles à mettre en œuvre car KARAF n'ont pas de classe de démarrage ou de classe de démarrage.

J'ai trouvé que Activation.jar Conflit a créé ce problème. . P>

{FUSEESB_HOME Or ServiceMIX_HOME}/etc/jre.properties was loading activation.jar .

Bien que j'aimerais en savoir plus sur les détails de la raison pour laquelle il s'agit d'un problème et de ce que cette option -xbootClassPath fait pour corriger le problème.

Cela a à voir avec l'arbre de classier. Rappelez-vous que les chargeurs de classe enfant sont autorisés à rechercher des cours dans le chargeur de classe des parents, mais pas l'inverse. Dans votre programme d'échantillon, l'arbre de classier ressemble à ceci: xxx

lorsque le logmanager $ logmanager $ $ Cleaner Crochet d'arrêt (JDK6 +) le Context Classloader est obligé de Bott Classloader incapable de localiser le com.sun.mail.HandLers. text_plain classe car il est dans un chargeur de classe enfant. À cause de cela, Modification de la messagerie Mailcapcommandmap pour inclure le mailcap Les noms de classe ne résoudront pas le problème. Lorsque vous utilisez l'option -XBOOTCLASSPATH , vous placez toutes les classes pertinentes du chargeur de classement de démarrage qui est visible au logManager $ logManager $ dollder . Cependant, ne modifiez pas votre système pour utiliser -xbootclasspath pour corriger ce problème.

à la place, mettez à niveau sur JavaMail 1.5.3 ou ultérieure qui contient la solution pour BOGUE K6552 | GH133 - Utilisez une ergonomie de classier dans la mailhandler . Si vous souhaitez mettre à niveau le module JavaMail de Glassfish, vous pouvez remplacer le Glassfish-XX / Glassfish / Modules / Javax.mail.jar avec une nouvelle version de JavaMail.

L'incomplet Fix appliqué à JavaMail 1.4.7 était de définir le chargeur de classe de contexte sur le chargeur de classe qui chargés le mailhandler pendant près. L'hypothèse est que le chargeur de classe qui a chargé le Mailhandler doit pouvoir trouver le code d'activation.

Si vous ne pouvez pas passer à une version plus récente de JavaMail, vous devez appliquer L'une des solutions suivantes:

1. Flush ou fermez la messagerie avant que le nettoyeur fonctionne.
2. Rincer tous les gestionnaires avant que le nettoyeur fonctionne (c'est-à-dire une application Web Undépape). Vous devez synchroniser sur le logmanager et collecter tous les gestionnaires de chaque enregistreur. Rincez tous les médicaments à l'extérieur du bloc synchronisé.
3. Étendez la messagerie et remplacez-vous près de définir et de restaurer le chargeur de classe de contexte si le chargeur de classe de contexte est NULL.
4. Installez un nouveau logManager et de remplacement réinitialiser pour définir et restaurer le chargeur de classe de contexte si le chargeur de classe de contexte est null.
5. Installez un formateur de sujet pour définir le chargeur de classe de contexte si le nettoyeur est en cours d'exécution.
6. Définissez le niveau de push sur TOUT ou définissez la capacité à 1 afin qu'un e-mail soit envoyé pour chaque enregistrement de journal et être spammé.
7. Exécutez sur une version Java avec patchée avec RFE JDK-8025251.

   Le problème principal est que le logManager $ logManager $ Fermer sur chaque enregistré avec le logManager . Un meilleur choix pour le logmanager aurait été de définir le chargeur de classe de travail sur le chargeur de classe de manutention avant d'appeler la fermeture, puis une fois que tous les gestionnaires sont fermés, définissez le chargeur de classe de contexte sur NULL. Cela pourrait toujours être dupe en nidifiant les gestionnaires mais au moins cela aurait fixé le cas commun. Ceci a été déposé comme rfe JDK-8025251 "Le nettoyeur de logManager doit utiliser le chargeur de classeur de manutention pendant fermer ".