Prohibited package name: java.lang ... - Java - Programmation
Marsh Posté le 21-12-2004 à 17:45:36
ReplyMarsh Posté le 21-12-2004 à 17:46:23
et c'est quoi la classe de xalan qui pose problème ?
Marsh Posté le 21-12-2004 à 17:53:48
L'exception est levée sur le newInstance
Code :
|
Pour être plus précis, il faut le package xsltc de xalan. Je te donne la méthode dessuite
Marsh Posté le 21-12-2004 à 17:59:12
bon, iplanet a planté et ne se relance plus... je m'en occupe et je te donne la réponse dans quelques minutes
Marsh Posté le 21-12-2004 à 18:36:44
bon, apres un reboot de la station et quelques autres soucis, voici ta reponse benou :
CORE3283: stderr: ERROR: 'org.apache.xml.utils.XMLChar.isValidQName(Ljava/lang/StringZ'
Marsh Posté le 21-12-2004 à 19:10:11
ben ca c'est une classe apache, elle est pas dans le JDK ... comment il pourrait y avoir un conflit ?
Marsh Posté le 22-12-2004 à 09:23:52
Il me semble que dans le jdk 1.4.2_02 il y a une version de xalan. D'où le conflit.
Marsh Posté le 22-12-2004 à 09:39:03
houlà ... ok. tin c'est la merde ca !
regarde ce côté là : http://xml.apache.org/xalan-j/faq.html#faq-N100CC
la technique du <java-home>\lib\endorsed devrait marcher je pense ...
Marsh Posté le 22-12-2004 à 09:46:36
Je ne peux malheureusement pas passer par le <java-home>\lib\endorsed. Notre client dispose de plusieures applications tournant sur le même serveur. Je ne pourrais pas leur faire installer un nouveau iplanet avec une autre installation du jdk.
Quant au XbootClasspath/p, j'ai commencé par utiliser ça. Cela fonctionne tres bien avec tomcat, mais je n'ai pas reussi à le mettre en place pour iplanet... il ne semble pas prendre en compte cette option...
Code :
|
tout ça etant mis dans l'onglet "mon_appli/java/JVM Options" d'iplanet
Marsh Posté le 22-12-2004 à 09:52:05
ReplyMarsh Posté le 22-12-2004 à 09:55:15
clair
Marsh Posté le 22-12-2004 à 10:07:14
je connais du tout iplanet donc je peux pas trop t'aider là dessus, mais je pense que dans ton cas faut que tu creuses pour faire marcher le Xbootclasspath ...
la redefinission du classloader est une bidouille qui risque de t'attirer pas mal de problèmes ...
Marsh Posté le 22-12-2004 à 11:40:32
oui et non, c'est en place sous cocoon et ca marche bien. Je vais quand même creuser le xboot et je te previens quand (si ) ca marche. En tout cas, merci de ton attention. Je retourne en reunion.
Fred
Marsh Posté le 22-12-2004 à 15:05:27
Bon, c'est résolu, il fallait utiliser l'option -Djava.endorsed.dirs, la faire pointer sur un repo contenant les jars. Ceci pouvant etre configuré pour une instance donnée d'un serveur, c'est parfait.
Fred
Marsh Posté le 22-12-2004 à 16:12:00
Merci pour la solution ... j'ai dans l'idée que tu seras pas le seul à avoir le problème ...
Marsh Posté le 21-12-2004 à 17:36:16
bonjour,
Suite à quelques problèmes de performance rencontrés sur des transformations xsl, j'ai mis en place du xsltc: au premier appel au transformer, les informations utiles à la transformation sont conservées (un translet static, un singleton qui l'utilise et retourne un transformer et le tour est joué).
Tout ceci fonctionne très bien sur mon environnement de dev (jdk 1.4.2_02 & tomcat 5.0.19) en faisant attention de poser dans le endorsed de tomcat le jar de xalan qui va bien
Sur sun one web server (iplanet 6), avec le même jdk, cela ne fonctionne pas aussi bien : les classes du jdk étant prioritaires sur celles des jars inclus au projet, j'ai un magnifique conflit sur une des methodes du jar de xalan.
Je me suis donc inspiré du classloader de cocoon qui permet de résoudre ce genre de problèmes : Le ParanoidClassLoader et la ParanoidServlet
J'ai adapté la ParanoidServlet à mon code
et mon code crash lors de l'instanciation de la servlet
Je récupère une SecurityException : Prohibited package name: java.lang
Le nom de la servlet est correct et son package n'est pas java.lang.TestServlet ...
Je n'ai rien trouvé de concluant sur google ou autre à ce sujet et je sèche ...
Auriez vous une idée ?
fred