Erik Bruchez wrote:
>Frédéric Glorieux wrote:
>
> > Désolé d'avoir été franco-centrique, mon patron est canadien, mon
> > père habite en Belgique.
>
>Aucun probleme !
>
> > 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.
>
> > 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.
> > Et bien pour les bugs que vous avez repéré, j'irai voir vos patches.
> > C'est certainement de l'information utile pour beaucoup de monde.
>
>Je crois que la plupart des changements ont ete faits dans dom4j, qui
>n'avait pas vu de nouvelle distribution depuis longtemps.
>
> > 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
>
> > Je suppose qu'Orbeon ne peut pas compter sur la même quantité de
> > développeurs qu'un projet Apache, ce qui probablement permet aussi
> > de garder la cohérence d'une vision, comme ce que je crois
> > comprendre de XPL. Mais là je reste encore observateur ces jours ci
> > (manque de temps).
>
>C'est un bon resume de la situation.
>
>
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.
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.
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
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 Wed Sep 29 10:16:47 2004
