> Oui, mais à tors ou à raison, je préférerais procéder différemment et
> faire en sorte que les installations de Cocoon et de mon application
> soient le plus indépendantes possible : je voudrais par exemple pouvoir
> faire tourner l'installation standard de Cocoon et ses exemples et mon
> application en parallèle sur des ports différents au lieu de les
> "mélanger" ou encore pouvoir tester mon application sur une nouvelle
> version en ne modifiant que quelques variables d'environnement.
De façon plus modeste, je fais marcher chez moi (pas encore en
exploitation) un même webapp dans plusieurs contextes (au sens servlet)
tournant avec un même tomcat. Mais, cela veut dire que le webapp doit
être complètement "read", que rien ne s'y écrive.
Ce n'est pas le cas du Cocoon défaut. Par exemple, il installe ses logs
dans le webapp. Le chemin des logs sont déclarés dans le logkit.xconf.
Un chemin abolu ne peut rien résoudre, les chemins relatifs non plus
(tomcat est démarré par un même scripts pour plusieurs contextes). Il me
fallait résoudre les chemins relatifs des logs par rapport à un dossier
unique pour chaque contexte démarré, je n'en vois qu'un : le dossier work.
Le problème serait le même pour bien d'autres choses, index lucene, base
SQL...
J'ai donc du salement patcher la classe de lancement de la servlet pour
passer le chemin du répertoire work au parseur du logkit.xconf. J'en ai
profité pour aussi donner la valeur en variable de contexte.
Si un cocooner écoute, je serais content qu'il me corrige, ou que soit
commiter l'idée :
Pouvoir résoudre dans logkit.xconf
<filename>${context-work}/WEB-INF/logs/core.log</filename>
voire
<filename>${context-ma_variable}/WEB-INF/logs/core.log</filename>
(ma_variable passée en paramètre d'initialisation de la servlet,
surchargeable par une variable de contexte)
> Ce que j'avais imaginé et documenté sur http://dev.xmlfr.org/CoCoon (et
> cela marchait bien en 2.1.3) c'est la chose suivante :
>
> * Une installation Cocoon en "standalone-demo".
> * Indépendamment de cette installation (sous une autre racine),
> l'installation de l'application.
> * Sous la racine de l'application, un script "cocoon.sh"
> légèrement modifié (je n'ai pas trouvé comment éviter cette
> modification) permettant de lancer une instance de Cocoon
> faisant appel aux librairies et classes de Cocoon (identifiées
> par une variable d'environnement) mais utilisant pour le reste
> l'environnement de l'application.
>
> Est-ce une démarche qui a déjà été tentée? que vous encourageriez?
J'ai installé chez moi le cocoon xmlfr à l'époque, mais pour être
honnête, j'ai brutalement copier/coller le "standalone-demo" pour que ça
marche (et puis je suis en windows, je du me faire un .bat)
> En théorie, si cela marche, je dois pouvoir installer une nouvelle
> version de Cocoon dans un autre répertoire, modifier mes variables
> d'environnement pour pointer sur cette nouvelle installation, relancer
> Cocoon et utiliser cette nouvelle installation.
>
> Le problème lorsque je passe de 2.1.3 à 2.5.1.1 avec cette méthode c'est
> que plus Cocoon ne démarre plus. Je n'ai pas eu le temps de trouver
> pourquoi, mais je pense qu'il doit y avoir trop d'adhérences entre le
> script cocoon.sh, les fichiers de configuration et les classes et
> librairies pour pouvoir facilement faire ce type de chose.
>
> Peut-être devrais-je comme tu le dis constituer certains fichiers de
> configuration en patchant les fichiers Cocoon?
Bon courage, mais est-ce que cela ne risque pas non plus d'adhérer à
l'état actuel de Cocoon ?
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Received on Thu Sep 9 19:09:02 2004
