InvocationTargetException Class.forname au changement de locale
2 réponses
Francois Cartegnie
Bonjour,
Je n'arrive pas à identifier la raison d'une levée
d'InvocationTargetException suite à un changement de locale vers UTF8 de
l'utilisateur éxécutant le code.
Le code incriminé (marche en locale non UTF8):
container.add(Class.forName("Dev."+defaultname).newInstance());
L'exception:
java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.ja
va:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccesso
rImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
Le nom de la classe ne contient que des caractères ASCII.
J'ai tenté de convertir l'encodage des fichiers source sans succès.
Si qqu'un a une idée...
Francois
--
Ce message est transmis sur Usenet à titre non commercial.
Toute reprise par un média non conforme à la RFC1036
(suppression partielle ou totale des entetes, non respect des messages
de controle le concernant), dénaturation ou exploitation commerciale
par insertion publicitaire, ofuscation ou changement du groupe ou du
destinataire initial est prohibée et contrevient à mon droit d'auteur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mayeul
Francois Cartegnie wrote:
Bonjour,
Je n'arrive pas à identifier la raison d'une levée d'InvocationTargetException suite à un changement de locale vers UTF8 de l'utilisateur éxécutant le code.
[snip]
Le nom de la classe ne contient que des caractères ASCII. J'ai tenté de convertir l'encodage des fichiers source sans succès.
Si qqu'un a une idée...
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à l'intérieur du constructeur de la classe appelée. C'est donc le constructeur par défaut de la classe en question, qui lance une exception depuis le changement vers utf-8. C'est ce constructeur qu'il faut étudier pour voir ce qui se passe.
Bien sûr, il est dommage que nous n'ayons pas la stack trace complète.
-- Mayeul
Francois Cartegnie wrote:
Bonjour,
Je n'arrive pas à identifier la raison d'une levée
d'InvocationTargetException suite à un changement de locale vers UTF8 de
l'utilisateur éxécutant le code.
[snip]
Le nom de la classe ne contient que des caractères ASCII.
J'ai tenté de convertir l'encodage des fichiers source sans succès.
Si qqu'un a une idée...
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni
l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à
l'intérieur du constructeur de la classe appelée.
C'est donc le constructeur par défaut de la classe en question, qui
lance une exception depuis le changement vers utf-8. C'est ce
constructeur qu'il faut étudier pour voir ce qui se passe.
Bien sûr, il est dommage que nous n'ayons pas la stack trace complète.
Je n'arrive pas à identifier la raison d'une levée d'InvocationTargetException suite à un changement de locale vers UTF8 de l'utilisateur éxécutant le code.
[snip]
Le nom de la classe ne contient que des caractères ASCII. J'ai tenté de convertir l'encodage des fichiers source sans succès.
Si qqu'un a une idée...
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à l'intérieur du constructeur de la classe appelée. C'est donc le constructeur par défaut de la classe en question, qui lance une exception depuis le changement vers utf-8. C'est ce constructeur qu'il faut étudier pour voir ce qui se passe.
Bien sûr, il est dommage que nous n'ayons pas la stack trace complète.
-- Mayeul
Francois Cartegnie
Mayeul wrote:
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à l'intérieur du constructeur de la classe appelée. C'est donc le constructeur par défaut de la classe en question, qui lance une exception depuis le changement vers utf-8. C'est ce constructeur qu'il faut étudier pour voir ce qui se passe.
Merci.
En sachant que c'était sous-jacent au constructeur, j'ai fini par remonter les multiples constructeurs et trouver l'erreur. Le changement de charset engendrait un défaut de lecture de données en passant par défaut les Inputstreamreader en UTF-8. Les données étant transmises en gzip, le charset était alors ignoré dans la réponse http en faveur du content-encoding. J'ai forcé les streamreaders sur la bonne locale, pas très propre, mais j'ai pas d'autre solution sous la main.
Francois
-- Ce message est transmis sur Usenet à titre non commercial. Toute reprise par un média non conforme à la RFC1036 (suppression partielle ou totale des entetes, non respect des messages de controle le concernant), dénaturation ou exploitation commerciale par insertion publicitaire, obfuscation ou changement du groupe ou du destinataire initial est prohibée et contrevient à mon droit d'auteur.
Mayeul wrote:
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni
l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à
l'intérieur du constructeur de la classe appelée.
C'est donc le constructeur par défaut de la classe en question, qui
lance une exception depuis le changement vers utf-8. C'est ce
constructeur qu'il faut étudier pour voir ce qui se passe.
Merci.
En sachant que c'était sous-jacent au constructeur, j'ai fini par
remonter les multiples constructeurs et trouver l'erreur.
Le changement de charset engendrait un défaut de lecture de données en
passant par défaut les Inputstreamreader en UTF-8. Les données étant
transmises en gzip, le charset était alors ignoré dans la réponse http
en faveur du content-encoding. J'ai forcé les streamreaders sur la bonne
locale, pas très propre, mais j'ai pas d'autre solution sous la main.
Francois
--
Ce message est transmis sur Usenet à titre non commercial.
Toute reprise par un média non conforme à la RFC1036
(suppression partielle ou totale des entetes, non respect des messages
de controle le concernant), dénaturation ou exploitation commerciale
par insertion publicitaire, obfuscation ou changement du groupe ou du
destinataire initial est prohibée et contrevient à mon droit d'auteur.
Je ne crois pas que ce soit le nom de la classe qui soit incriminé. Ni l'encodage des fichiers sources, encore que ça soit une possibilité.
InvocationTargetException indique qu'une exception est arrivée à l'intérieur du constructeur de la classe appelée. C'est donc le constructeur par défaut de la classe en question, qui lance une exception depuis le changement vers utf-8. C'est ce constructeur qu'il faut étudier pour voir ce qui se passe.
Merci.
En sachant que c'était sous-jacent au constructeur, j'ai fini par remonter les multiples constructeurs et trouver l'erreur. Le changement de charset engendrait un défaut de lecture de données en passant par défaut les Inputstreamreader en UTF-8. Les données étant transmises en gzip, le charset était alors ignoré dans la réponse http en faveur du content-encoding. J'ai forcé les streamreaders sur la bonne locale, pas très propre, mais j'ai pas d'autre solution sous la main.
Francois
-- Ce message est transmis sur Usenet à titre non commercial. Toute reprise par un média non conforme à la RFC1036 (suppression partielle ou totale des entetes, non respect des messages de controle le concernant), dénaturation ou exploitation commerciale par insertion publicitaire, obfuscation ou changement du groupe ou du destinataire initial est prohibée et contrevient à mon droit d'auteur.