Laurent Perez wrote:
Hello
Je cherche à pouvoir toucher Cocoon à partir de ma couche de
composants Spring : quelque chose de très basique, c'est à dire
pouvoir récupérer la sortie XML d'un <map:match pattern="xx">. Tous
mes composants Spring sont déclarés dans mon applicationContext.xml,
qui est chargé par le web.xml de la webapp Cocoon.
Le block spring-app dans le trunk (1) ressemble à ce que je cherche à
faire : org.apache.cocoon.core.Core apparait comme un bean
"cocoon-core" dans l'applicationContext.xml. Je suppose qu'à partir du
moment où je peux toucher au Core, il doit bien y avoir un moyen de
toucher une sitemap ensuite (?).
Seulement spring-app n'est pas du tout documenté, et je ne sais pas
s'il est plutôt fait pour toucher Spring à partir de Cocoon, ou
l'inverse. Ensuite je me demande si exposer directement le Core n'est
pas overkill pour ce que je cherche à faire.
Quelqu'un pourrait-il m'éclairer sur ce point ?
Le block spring-app tire parti de la réarchitecture de la gestion des
composants qui a été faite dans la future version 2.2.
L'idée de initiale part du constat que Avalon, à la base de Cocoon,
n'est plus le seul conteneur léger sur le marché et qu'il est nécéssaire
d'intégrer les conteneurs plus modernes comme Spring, Hivemind ou Pico.
Dans la version 2.1, il est facile d'intégrer ces conteneurs "à
l'intérieur" de Cocoon, mais en gardant une barrière relativement
étanche entre les différents mondes. Voir le bricks-cms de Bertrand [1]
ou la présentation de Ugo Cei à la GetTogether 2004 [2].
Dans la version 2.2, il y a un pont entre des conteneurs divers hébergés
par Cocoon. Concrètement, cela signifie qu'un composant géré par Avalon
pourra voir un composant Spring comme s'il était géré par Avalon, et
réciproquement.
Pour revenir à ton problème, il devrait suffire que tu puisses accéder
au SourceResolver pour appeler un pipeline avec "cocoon://xxx", et il
faut donc "l'injecter" dans l'ApplicationContext Spring. Je suppose que
tu utilises le ServletContextListener déclaré dans web.xml, ce qui
malheureusement va instancier tous les beans avant que Cocoon aie créé
ses composants, dont le SourceResolver.
Une solution est de déclarer dans le contexte Spring une implémentation
"fantôme" de SourceResolver, prête à déléguer au "vrai" resolver
lorsqu'il sera disponible, et qui sera utilisée par les autres beans.
Dans la partie Cocoon de l'appli, soit via un petit composant
ThreadSafe, soit juste avant d'appeler les beans Spring, tu donnes le
"vrai" resolver au fantôme, ce qui permet aux beans d'accéder aux
pipelines Cocoon.
C'est du design en direct et je ne l'ai pas testé, mais ça devrait faire
l'affaire !
Sylvain
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/example-apps/bricks-cms/
[2] http://www.apache.org/dist/cocoon/events/gt2004/presentations/
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.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]
