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
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. 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.
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).
--
Frédéric Glorieux ("AJLSM", <http://ajlsm.com>)
"Transfolio" <http://transfolio.org>
--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
