Frédéric Glorieux wrote:
L'habitude va changer, puisque faire le ménage consistera en 2.2 à enlever les fichiers .xconf des blocks non utilisés. Il ne sont plus fusionnés dans un seul xconf global.
J'ai lu en effet :o)
A chaque mise à jour cocoon, on se trouvait parfois avec quelques surprises en revoyant son cocoon.xconf et ses sitemap.
Et c'est en grande partie pour ça que j'ai ajouté cette fonction d'include ;-)
Autre chose que cela semble annoncer, depuis longtemps je vois dans le sitemap racine la déclaration pour servir les dossiers personnels (~user). Je ne sais pas trop qui utilise, mais dans le même esprit, est-ce que vous vous avancez vers un standard d'hébergement cocoon mutualisé ?
L'hébergement mutualisé sur une instance de Cocoon n'est pas à l'ordre du jour parce qu'il faudrait construire des barrières étanches au niveau code, données et accès au filesystem entre les différentes applications hébergées. Pas impossible à faire, mais compliqué. Et comme c'est exactement ce que fait un moteur de servlets entre les différents applications web (war, context, webapp selon les environnements), on ne va pas entamer la réécriture de ce code dans Cocoon !
Compris. Nous ne l'avons jamais fait, mais j'imagine par contre que dans une entreprise, ou une université (collaborateurs supposés bienveillants) on peut partager ensemble un même cocoon.
Oui. C'est une des applications possibles du pattern "~*/**" dans la sitemap racine des exemples. Mais il ne faut pas oublier que ce ne sont _que_ des exemples :-)
Si je comprends, au delà d'un cocoon standard, on peut désormais avoir plus qu'un sitemap défaut, mais aussi ses classes, voir ses jars à soi ? C'est déjà très bien ! Merci encore.
Oui, on peut avec la version "trunk" de Cocoon (la future 2.2) avoir une déclaration de classpath dans chaque sitemap. Un répertoire contenant une sous-sitemap peut ainsi devenir un "block" complet et autonome (mais pas étanche!)
Par contre, il est parfaitement possible de déployer toutes les librairies de Cocoon dans les parties communes à toutes les webapp pour ne charger qu'une fois les classes.
J'ai peur de demander, est-ce que vous auriez un petit lien là-dessus ? (cf autre thread).
C'est très dépendant du moteur de servlet. Pour Tomcat, il faut mettre les .jar correspondants dans shared/lib.
Voir http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
