>>>Je suppose que le classloader de cocoon depuis le XALAN en 1.4 m'a
>>>protégé de ce genre de choses. Mais est-ce à dire que je ne peux pas
>>>mettre la distribution officielle d'un jar dans orbeon ?
>>
>>Pour certains JARs, sans re-rooter, non. Pour XSLT, tout est tres
>>configurable sans modifier de code Java, mais le support de certains
>>features necessitent des classes de Saxon re-rootees. Pour le reste,
>>par exemple le parseur XML, il faudrait implementer une configuration
>>plus souple.
> Cocoon a une solution à ce problème de "jar hell" : le
> ParanoidCocoonServlet, qui encapsule un autre servlet dans un
> classloader étanche : toute classe ou ressource est d'abord cherchée
> dans WEB-INF/lib, même les classes systèmes (java.* et javax.*). Ca nous
> a sortis de nombre de problèmes liés à des incompatibilités entre les
> Xerces/Xalan du JDK et ceux de Cocoon, un classloader buggé dans
> certaines versions de Tomcat, etc, etc.
>
> Cette technique évite le re-rootage des jars externes.
Désolé d'ajouter une voix d'utilisateur moyen, mais pour moi, c'est un
argument décisif contre "Presentation Server" dans l'état, mais pas
contre les concepts que je pourrais en apprendre, j'y reviens.
>>>Mmmh, pas gentil pour ceux qui ont une autre machine virtuelle. Je
>>>veux juste dire que j'aime assez que cocoon me permette de caler des
>>>xsp (sorte de jsp) qui se compilent à partir d'une jre.
>>
>>Oui, c'est vrai. J'ai entre un RFE pour suivre ceci:
>>
>>http://sourceforge.net/tracker/index.php?func=detail&aid=1036684&group_id=116683&atid=675663
Cette réactivité vous honore, mais s'il on voit aussi le point du
dessus, et bien d'autres qui pourraient surgir de la comparaison, reste
à voir si vous avez les moyens de suivre. A moins que de passer dans le
libre soit une stratégie de recrutement ?
> Je ne suis pas certain que le nombre de développeurs dilue la vision.
> Dans le cas de Cocoon, même s'il n'y a pas de hiérarchie écrite, il y en
> a une de fait, et la vision est pilotée et entretenue par un petit
> nombre de personnes, au premier rang desquelles on trouve Stefano
> Mazzocchi, qui a créé Cocoon il y a 5 ans.
5 ans, déjà... Mais Mazzocchi, il est encore avec vous ? Je remercie
encore mon employeur de m'avoir mis sur un bon cheval, j'ai encore reçu
des propositions hier où des compétences cocoon étaient très recherchées.
> Le noyau de Cocoon est bien défini et stable, et le nombre de
> développeurs a plutôt apporté une richesse fonctionnelle avec un nombre
> important d'implémentations des interfaces de base du noyau. C'est ce
> qui donne ce côté peut-être un peu fouillis de Cocoon.
Et le passage aux blocs n'est pas vraiment convaincant. Nous avons du y
renoncer. Comme sans doute beaucoup, on se compose une servlet avec les
briques Cocoon (merci, mais il y a des trucs à bien tester qui ne
doivent tenir la prod que pour leurs auteurs), et on s'énnerve de toutes
les surcouches qui nous cachent des choses claires et documentées.
Un exemple, la response HTTP. Je crois que c'est Mazzochi le coupable
avec son désir d'abstraction, mais sous prétexte de CLI on a un
copié/collé sous un autre nom, désolé, mais pour moi cela s'appelle de
la mentalité propriétaire. Je ne reconnais pas là la qualité d'aller au
plus simple d'un certain cocooner qui nous a déjà montré son talent sur
cette liste (je le dis sincèrement parce que mes propositions pour la
même chose tenait plutôt de l'Usinagaz).
Ceci étant, je me suis livré 8 jours de vacances à tenter de me passer
de Cocoon (ce qui m'a donné l'occasion d'aller voir dans le code de
Tomcat et de Jetty), euhh... Saine épreuve à laquelle chacun devrait se
livrer sur ses convictions. J'y ai gagné une bien meilleure connaissance
de ce qu'il y a déjà, pourquoi prendre dessus quand le dessous suffit ?
Mais quand j'ai voulu voir les struts et consort... je suis revenu avec
joie dans mes générateurs.
> Cette dichotomie se retrouve d'ailleurs dans les formations Cocoon que
> je donne : la majeure partie du message est liée au fonctionnement de ce
> noyau et des implémentations de base (xslt, xinclude, xsp, forms, etc),
> puisque c'est ce que les utilisateurs doivent nécessairement maîtriser,
> et on donne des méthodes de recherche pour "faire son marché" dans le
> vaste choix des autres implémentations.
Orbeon aurez une solution assez commode pour profiter de cette puissance
et d'alléger la maintenance de choses résolue ailleurs, implémenter XPL
dans cocoon :o) (avant que quelqu'un d'autre ne le fasse). Qui irait
voir sous le capot de "Presentation Server" ? Je n'ai aucune compétence
commerciale mais j'ai l'impression que cela vous ouvrirait sur un marché
beaucoup plus large que de vous positionner contre cocoon, alors qu'à
terme les produits sont trop comparables pour ne pas devoir merger un
jour, sans d'ailleurs dire lequel mangerait l'autre. Cela demande je
suppose des efforts côté cocoon, mais là je n'ai rien à dire.
>>>Donc on pourra vous voir ici <http://www.orixo.com/events/gt2004/>
>>>;o) ?
>>
>>On risquerait de m'y jeter des pierres ;-) Serieusement, j'aurais
>>beaucoup d'interet a assister, mais ce n'est pas encore dans mes
>>plans.
Et on vous accueillerait comme un membre important au GT2005 ?
--
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 Fri Oct 1 13:22:10 2004
