- JSP
- Java Server Page. Réponse de SUN aux Application Server Page (ASP) de MicroSoft. Une JSP se présente sous la forme d'un fichier texte, mêlant du HTML (ou autre langage de présentation comme WML ou XML, même si ça n'est pas forcément très adapté) et du code qui peut prendre la forme de balises spécifiques, ou de scriplet (du Java) ou d'expressions EL. Ce fichier texte est ensuite converti en code source Java, puis compilé en une Servlet ; ce travail est effectué par le serveur d'application.
- WebSphere
- Nom fourre-tout donné par IBM à ses logiciels destinés aux serveurs. WebSphere Application Server, premier logiciel à entrer dans cette famille, est un serveur d'application Java.
- Servlet
- Première approche de SUN pour faire entrer Java dans le monde des serveurs web. Se dit de toute classe Java descendante de javax.servlet.Servlet, dont la méthode principale consiste à répondre à une requête émise par un client.
Notre problématique ici est qu'une JSP (simple fichier texte donc) est compilée en une classe Java tout à fait standard, et dans cette classe, une unique méthode (dans 98% des cas) va représenter tous les traitements effectués dans la page. Or en Java, une méthode ne peut comporter plus de 64 kilo octets (ko en français, kB en anglais) d'opérations élémentaires. La tendance ces dernières années a été de gorger les JSP de balises spécifiques (Struts et consors), et chaque utilisation de balise spécifique se traduit par un ensemble d'opérations élémentaires rajoutées dans la méthode qui représente la JSP compilée. Une fois cette limite atteinte, la page est trop grosse, et il faut la scinder en plusieurs fichiers, assemblés dynamiquement les uns avec les autres, et ce pour des raisons bassement techniques.
Cette limitation n'est pas spécifique à WebSphere, par contre cette limite sera atteinte plus ou moins vite en fonction du générateur de code source Java à partir de la JSP. Par exemple, Tomcat utilise Jasper pour cette tâche, de même que WebSphere, sauf que WebSphere utilise une version différente, qui a tendance à générer plus de code pour les mêmes opérations : la limite est plus vite atteinte sous WebSphere. Cette limite est par contre spécifique aux JSP, les autres technologies disponibles en Java côté serveur (comme Velocity, JDynamite, Template4Java, etc...) ne souffrent pas de ce problème, car elles ne reposent pas sur la génération dynamique d'une classe Java.
3 réactions
1 De yakafokon - 17/05/2004, 10:39
mmmh... ca m'etonne ce que tu dis car j'ai deja fait des ?crans avec des tags Struts et le resultat devait representer un fichier java intermediaire sacrement costaud du coup ton probleme des 64ko ca me semble louche.
Tiens d'ailleurs je viens de regarder un fichier java intermediaire qui est 680 ko et qui n'a jamais eu de problemes (remarque faut voir... car c'est blinde de commentaires).
Ca ne serait pas plutot un probleme d'autoflush au niveau de page jsp, ou quelque chose comme ca ?
2 De Damien B - 17/05/2004, 12:39
Non non, c'est bien comme ça que ça se passe. Il faut bien voir que 64ko pour une méthode c'est assez énorme, là où j'ai rencontré la limite c'était dans une page avec près d'une centaine de tags. Le 64k c'est une limite physique du format (bytecode) des fichiers .class.
Les problèmes de buffer sont différents.
3 De Damien B - 17/05/2004, 12:43
Petit test rapide. Une JSP me donne un code source Java de 230ko avec WebLogic 8, le fichier compilé fait 51ko, sur cette taille, la méthode _jspService représente 13.6ko : on est loin du compte. Si on applique le ratio sur ton fichier de 680ko (démarche fausse bien entendu), on arrive à 40ko. Il faut quand même bien pousser pour arriver aux 64ko, mais c'est possible :-)