Re: Cocoon, lucene et le fr ançais
* Bruno Merkele: Quel est la marche à suivre pour utiliser ce code dans Cocoon? Il faut mettre la classe compilée dans le répertoire WEB-INF/classes de ton application, dans une arborescence de répertoires conforme au nom du package de la classe. Dans mon application, j'ai un répertoire WEB-INF/classes/org/apache/lucene/analysis/fr/ contenant les différentes classes nécessaires à l'indexation Lucène en français. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
XMLDBSource, cacheable + questions
Bonjour, Je cherche à avoir un générateur xmldb cacheable. J'utilise Exist. Dans certains cas, Exist sait donner une date de modification (quand on demande une ressource précise). Il est possible que ceci puisse s'étendre aux collections, et donc aux requêtes effectuées sur une collection. Je fais marcher, mais je ne sais pas si c'est optimal. Comme je vois que Sylvain à toucher à XMLDBSource il y a moins de 3 semaines http://svn.apache.org/viewcvs.cgi/cocoon/blocks/xmldb/trunk/java/org/apache/cocoon/components/source/impl/ Mes questions ont peut être un peu d'actualité. (Je m'en suis d'ailleurs aperçu un peu tard. Je travaillais sur une vieille version de la classe, beaucoup moins bien factorisée) J'ai surchargé XMLDBSource.getValidity() pour qu'il renvoit un TimeStampValidity(lastModified) quand il est possible de récupérer un long lastModified. ça marche. (Je le vérifie avec une xsl qui me tagge le xml généré avec une date. Tant que je n'ai pas touché à la ressource Exist (ou à une xsl du tuyau) la date ne change pas, et si je modifie la ressource exist, tout est regénéré ) Maintenant, les questions que je me pose * Faut il fabriquer un TimeStampValidity à chaque fois que getValidity() est appelé ? * C'est certainement une mauvaise pratique, mais j'ai eu besoin d'un getter sur user:password, cela me permet de reprendre la connexion configurée en cocoon.xconf depuis ailleurs * J'imagine que tant que l'api xmldb ne proposera pas un équivalent de getLastModified() ce ne serait pas une bonne pratique de mettre ce genre de choses selon chaque implémentation xmldb ? -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Bonjour Frédéric, Pour les requêtes effectuées en XQuery, tu peux utiliser XQueryGenerator qui est cacheable avec un paramètre optionnel de durée de validité. En ce qui concerne XMLDBSource, voici quelques réponses à tes questions: * Faut il fabriquer un TimeStampValidity à chaque fois que getValidity() est appelé ? Oui, cette méthode n'est appellée à nouveau que quand la source n'est plus valide. * C'est certainement une mauvaise pratique, mais j'ai eu besoin d'un getter sur user:password, cela me permet de reprendre la connexion configurée en cocoon.xconf depuis ailleurs Là je n'ai pas trop compris, pourquoi as-tu besoin de récupérer user et password alors qu'ils sont déjà configuréscorrectement danscocoon.xconf surdriver class=org.exist.xmldb.DatabaseImpl...? * J'imagine que tant que l'api xmldb ne proposera pas un équivalent de getLastModified() ce ne serait pas une bonne pratique de mettre ce genre de choses selon chaque implémentation xmldb ? En effet difficile de l'intégrer à Cocoon si ça n'est pas dans l'interface. Attention à getLastModified(), cela n'est pas satisfaisant pour une XQuery car pour calculer la date de modification on est obligé de rééxecuter la XQuery. Attention aussi quand l'application accède à eXist par le réseau, getLastModified() a alors le coût de transport et le coût de consultation de la base de données XML, y compris quand tu accèdes simplement à un document sans requête XQuery ou XPath. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Frédéric Glorieux wrote: Bonjour, Je cherche à avoir un générateur xmldb cacheable. J'utilise Exist. Dans certains cas, Exist sait donner une date de modification (quand on demande une ressource précise). Il est possible que ceci puisse s'étendre aux collections, et donc aux requêtes effectuées sur une collection. Je fais marcher, mais je ne sais pas si c'est optimal. Comme je vois que Sylvain à toucher à XMLDBSource il y a moins de 3 semaines http://svn.apache.org/viewcvs.cgi/cocoon/blocks/xmldb/trunk/java/org/apache/cocoon/components/source/impl/ Mes questions ont peut être un peu d'actualité. (Je m'en suis d'ailleurs aperçu un peu tard. Je travaillais sur une vieille version de la classe, beaucoup moins bien factorisée) J'ai surchargé XMLDBSource.getValidity() pour qu'il renvoit un TimeStampValidity(lastModified) quand il est possible de récupérer un long lastModified. ça marche. J'ai vu ces méthodes complémentaires sur l'interface EXistResource qu'il serait bien pratique d'utiliser pour avoir une implémentation plus complète de l'interface Source. Malheureusement, la license d'Exist interdit ces extensions spécifiques d'être utilisées dans le code disponible chez Apache... (Je le vérifie avec une xsl qui me tagge le xml généré avec une date. Tant que je n'ai pas touché à la ressource Exist (ou à une xsl du tuyau) la date ne change pas, et si je modifie la ressource exist, tout est regénéré ) Maintenant, les questions que je me pose * Faut il fabriquer un TimeStampValidity à chaque fois que getValidity() est appelé ? Oui. La création d'un petit objet n'est pas coûteuse, et si on le gardait dans l'objet Source, cela complexifierait inutilement le code pour la gestion d'état. * C'est certainement une mauvaise pratique, mais j'ai eu besoin d'un getter sur user:password, cela me permet de reprendre la connexion configurée en cocoon.xconf depuis ailleurs Ca n'est pas forcément une mauvaise pratique. Lorsqu'on est sûr de l'implémentation concrète de Source qu'on utilise, des méthodes supplémentaires peuvent faciliter la vie. FileSource par exemple, permet d'accéder au File sous-jacent. Je pensais d'ailleurs mettre un accès public à la ressource et la collection dans XMLDBSource. Ca pourrait aider? * J'imagine que tant que l'api xmldb ne proposera pas un équivalent de getLastModified() ce ne serait pas une bonne pratique de mettre ce genre de choses selon chaque implémentation xmldb ? C'est plus une question de licence que de bonne pratique... Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net 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]
Re: Meme session sur plusieurs domaines
Merci beaucoup, j'etais totalement bloqué. Phil On 12/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Philippe Guillard wrote: Bonjour, (suite sujet Basique question de session et url rewrite) - Beaucoup de sites implementent une authentification valable sur plusieurs prefixes ajoutes au meme nom de domaine sans inclure de session id dans les urls, donc j'imagine une certaine quantite sont realises via servlet et le session tracking est fait via un cookie. Quelqu'un sait-il comment ceci peut etre realise? - Est-il possible sur cocoon d'empecher le session tracking via le cookie et utiliser exclusivement le transformer urlrewrite? La gestion des sessions est différente de la gestion de l'authentification. Ce que tu cherches est peut-être le single sign on, qui permet à un utilisateur de s'identifier une seule fois pour toutes les applications d'un même serveur. Tomcat propose cette fonctionnalité : http://tomcat.apache.org/tomcat-5.0-doc/config/host.html#Single%20Sign%20On Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net 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]
Re: XMLDBSource, cacheable + questions
Bonjour Frédéric, Bonjour, Bravo à Anyware pour la réactivité ! Pour les requêtes effectuées en XQuery, tu peux utiliser XQueryGenerator qui est cacheable avec un paramètre optionnel de durée de validité. Je le cherchais dans les sources Cocoon... Donc, dans Exist, c'est déjà ça, new ExpiresValidity(). Attention à getLastModified(), cela n'est pas satisfaisant pour une XQuery car pour calculer la date de modification on est obligé de rééxecuter la XQuery. Vu la quantité d'informations qu'ils maintiennent, il peuvent probablement faire mieux. J'ai poussé sur la liste Exist en espérant un commit pour avoir un getLastModified() au niveau d'une collection. En ce cas, si la collection de contexte d'une xquery n'a pas changé, les résultats seront les mêmes ? Là je n'ai pas trop compris, pourquoi as-tu besoin de récupérer user et password alors qu'ils sont déjà configuréscorrectement danscocoon.xconf surdriver class=org.exist.xmldb.DatabaseImpl...? Dans le contexte Sitemap, inutile, tout fonctionnne. Cependant, pour certaines opérations, il est nécessaire de pouvoir récupérer en JAVA une Collection xmldb (pour par exemple un service UserManagement) Comme XMLDBSource à tout le nécessaire pour récupérer une collection, selon les informations qu'aura autorisé un administrateur dans un cocoon.xconf, et ne sachant pas lire en JAVA un cocoon.xconf, j'ai trouvé cette solution pratique (pour être franc, j'ai seulement recompilé avec public au lieu de protected) Attention aussi quand l'application accède à eXist par le réseau, getLastModified() a alors le coût de transport et le coût de consultation de la base de données XML, y compris quand tu accèdes simplement à un document sans requête XQuery ou XPath. En effet, je n'y avais pas pensé. Je fonctionnne en local, mais s'il fallait être générique, il faudrait alors un truc du genre aller voir le lastModified toutes les secondes s'il s'agit d'une RemoteCollection. * Faut il fabriquer un TimeStampValidity à chaque fois que getValidity() est appelé ? Oui, cette méthode n'est appellée à nouveau que quand la source n'est plus valide. OK, donc pour ça c'est bon. En effet difficile de l'intégrer à Cocoon si ça n'est pas dans l'interface. Normal. -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
* Frédéric Glorieux: Pour les requêtes effectuées en XQuery, tu peux utiliser XQueryGenerator qui est cacheable avec un paramètre optionnel de durée de validité. Je le cherchais dans les sources Cocoon... Donc, dans Exist, c'est déjà ça, new ExpiresValidity(). En effet, XQueryGenerator est dans les sources d'eXist, désolé de ne pas l'avoir mentionné. C'est dommage que le bloc XMLDB de Cocoon soit si éloigné d'eXist, cela est probablement du à la stagnation de l'API XMLDB. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit : ...Bravo à Anyware pour la réactivité !.. A propos, il se passe des choses sympa sur cocoon-dev: http://marc.theaimsgroup.com/?t=11352590362r=1w=2 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: XMLDBSource, cacheable + questions
J'ai vu ces méthodes complémentaires sur l'interface EXistResource qu'il serait bien pratique d'utiliser pour avoir une implémentation plus complète de l'interface Source. Malheureusement, la license d'Exist interdit ces extensions spécifiques d'être utilisées dans le code disponible chez Apache... C'est plus une question de licence que de bonne pratique... :o( En ce cas, c'est à Exist de proposer son implémentation d'un cocoon Source plus complet ? Oui. La création d'un petit objet n'est pas coûteuse, et si on le gardait dans l'objet Source, cela complexifierait inutilement le code pour la gestion d'état. Oui, à part le cas relevé par Jean-Baptiste Quenot, cela peut coûter d'aller voir à chaque fois, si l'instance xmldb est distante. * C'est certainement une mauvaise pratique, mais j'ai eu besoin d'un getter sur user:password, cela me permet de reprendre la connexion configurée en cocoon.xconf depuis ailleurs Ca n'est pas forcément une mauvaise pratique. Lorsqu'on est sûr de l'implémentation concrète de Source qu'on utilise, des méthodes supplémentaires peuvent faciliter la vie. FileSource par exemple, permet d'accéder au File sous-jacent. Voilà, c'est ce genre de choses. Je pensais d'ailleurs mettre un accès public à la ressource et la collection dans XMLDBSource. Ca pourrait aider? Beaucoup plus propre ! J'avais mis user:pass à public sur une vieille version de XMLDBSource, la collection et la ressource n'était pas factorisée, mais en effet, un mot de passe ne se ballade pas comme ça n'importe où. -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Bertrand Delacretaz wrote: Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit : ...Bravo à Anyware pour la réactivité !.. A propos, il se passe des choses sympa sur cocoon-dev: http://marc.theaimsgroup.com/?t=11352590362r=1w=2 Désolé, je ne suis plus inscrit côté anglais, mais je vote OUI ! -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Bertrand Delacretaz wrote: Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit : ...Bravo à Anyware pour la réactivité !.. A propos, il se passe des choses sympa sur cocoon-dev: http://marc.theaimsgroup.com/?t=11352590362r=1w=2 Le contingent de committers francophones va grossir de 50% ! Terrible :-) Bravo Jean-Baptiste... et joyeux Noël ;-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net 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]
[OT] 33% de committers francophones en plus ;-)
Le 22 déc. 05, à 15:08, Sylvain Wallez a écrit : ...Le contingent de committers francophones va grossir de 50% ! Terrible :-) 33%! Tu oublies Alfred Nathaniel qui travaille à Genève, il parle parfaitement le français aussi, bien que franchement polyglotte. Mais bon, que Jean-Baptiste représente 50% ou 33%, on est de toutes façons très contents ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: XMLDBSource, cacheable + questions
En ce cas, c'est à Exist de proposer son implémentation d'un cocoon Source plus complet ? Effectivement, je pense que ça serait une très bonne solution. Exist vient avec un certain nombre de composants Cocoon, alors pourquoi pas une source amélioriée? Je sais un commiter Exist qui écoute aussi ici. J'avais mis user:pass à public sur une vieille version de XMLDBSource, la collection et la ressource n'était pas factorisée, mais en effet, un mot de passe ne se ballade pas comme ça n'importe où. Ouaip :-) En y réfléchissant, je vois d'autres mauvaises raisons de rendre le user:pass public. Quand l'instance Exist est crée de neuf par DatabaseManager.registerDatabase(db) contre un fichier de conf, l'utilisateur souhaité en cocoon.xconf peut ne pas encore exister. Pour Exist, avec l'utilisateur défaut admin:null, je crée l'utilisateur demandé en cocoon.xconf. Est-ce bon à mettre en XMLDBSourceFactory ? Pour les backups (hors API xmldb), Exist demande aussi un user:pass. -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Expliquer ce qu'est un committer (était Re: XMLDBSource, cacheable + questions)
Jean-Baptiste Quenot wrote: Merci à tous, Voilà un beau cadeau de Noël. Par contre je ne sais pas trop comment je vais expliquer ça à mon entourage, j'ai bien envie de leur annoncer la nouvelle mais je ne sais pas comment m'y prendre, vous avez des idées? « Ca y est, je suis committer Cocoon » je pense qu'on risque de me regarder avec des gros yeux et de me répondre: « tu es Quoi? »... Bertrand as-tu une explication simple pour des non-informaticiens? Héhé, THE question :-) Tu peux dire je bosse à travers Internet avec des gens que je n'ai jamais vus, répartis sur toute la planète, sur un logiciel qui est disponible gratuitement pour qui en a envie. Je n'ai d'ailleurs aucun moyen de savoir qui sont ses utilisateurs. J'écris des parties de ce logiciel, et je viens d'obtenir le droit d'enregistrer ces parties sur des machines qui sont... à Los Angeles... à Amsterdam... je sais pas trop où en fait. Et je suis super-content. Et après, tu regardes leur tête ! Bon courage :-P Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net 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]
Expliquer ce qu'est un committer (était Re: X MLDBSource, cacheable + questions)
Le 22 déc. 05, à 18:45, Jean-Baptiste Quenot a écrit : Bertrand as-tu une explication simple pour des non-informaticiens? Euh...l'explication de Sylvain est bonne! Si on voulait imager plus, c'est un peu comme si on construisait une cathédrale (ouais, je sais c'est plutôt un bazar ;-) et que les committers sont ceux qui ont le droit de poser les pierres directement au bon endroit, au lieu de préparer les pierres que les autres vont poser. Et si le bon endroit ne plaît pas aux autres, ils retirent les pierres...et il faut discuter un peu pour se mettre d'accord ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: XMLDBSource, cacheable + questions
Bonsoir, Frédéric Glorieux wrote: Vu la quantité d'informations qu'ils maintiennent, il peuvent probablement faire mieux. J'ai poussé sur la liste Exist en espérant un commit pour avoir un getLastModified() au niveau d'une collection. Plus tard : En ce cas, c'est à Exist de proposer son implémentation d'un cocoon Source plus complet ? Puis après : Je sais un commiter Exist qui écoute aussi ici. Pensant être le dit commiter, je ne sais pas quoi répondre si ce n'est que ni la première fonctionnalité, ni la seconde ne font partie de mes priorités. Bien sûr, comme dans tout bon projet open source, tout un chacun, y compris Frédéric Glorieux ;-), peut s'y coller. Je puis comme d'habitude, et dans la mesure de mes moyens, donner des conseils. En attendant, voici mon avis : Le timestamp existe sur les collections et est même documenté dans les antiques Javadoc : http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp() La façon dont il est généré est un peu particulière car c'est une info fournie par le cache de collections, le truc bancal mais relativement efficace trouvé par eXist pour centraliser les opérations de lecture, écriture (et donc de verrouillage) et quelques autres goodies. De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il faut et, plus souvent, que son rafraîchissement n'est pas toujours correctement répercuté comme il se doit. Il y a pas mal de refactorings à faire là-dedans, avec des pincettes évidemment (je viens de me faire flamer pour avoir stabilisé une non-feature :-) En ce qui concerne la source Cocoon et sans vouloir rallumer la polémique sur les licences qui a meublé les premiers jours de cette liste, vous savez où il faut envoyer les patches :-) Je tiens seulement à indiquer que les URI eXist sont, hum, bancales et que j'ai écrit une classe XmldbURI pour essayer de mettre de l'ordre dans tous ça. Bien sûr, ça aurait été plus simple avec des specs xmldb blindées... mais, dans ce cas précis, je pense que l'implémentation fera la spec et non l'inverse : avis aux amateurs ! Je n'accapare pas plus la bande passante car on est assez loin de Cocoon. Il faut simplement se rendre compte que eXist c'était jusqu'à il y a peu un développeur et un conseiller scientifique. Même si la situation s'est améliorée, les contributeurs manquent cruellement et les efforts sont très difficiles à coordonner... J'ajoute que pas mal de dév se décident sur le Chat (auquel je n'ai accès que depuis chez moi :-( ). A+ p.b. M'enfin, ça sera mieux en 2006 :-) A+ p.b. - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Le timestamp existe sur les collections et est même documenté dans les antiques Javadoc : http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp() Oops, pas vu, je cherchais le symétrique à Resource.getLastModificationTime() Super ! La façon dont il est généré est un peu particulière car c'est une info fournie par le cache de collections, le truc bancal mais relativement efficace trouvé par eXist pour centraliser les opérations de lecture, écriture (et donc de verrouillage) et quelques autres goodies. De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il faut et, plus souvent, que son rafraîchissement n'est pas toujours correctement répercuté comme il se doit. Tu as une idée des risques encourus ? Le genre d'opérations qu'il faudrait faire suivre d'un nettoyage du cache pour avoir plus d'assurance ? tout un chacun, y compris Frédéric Glorieux ;-), peut s'y coller. Là dessus il ne vaut mieux pas me laisser faire. En ce qui concerne la source Cocoon et sans vouloir rallumer la polémique sur les licences qui a meublé les premiers jours de cette liste, vous savez où il faut envoyer les patches :-) Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir, mais cela ne fait pas des millions de lignes. snip/ En ce qui concerne les autres aspects de développements d'Exist, je comprends cet appel aux bonnes volontés, mais le défi est dur à relever. Il faut non seulement du temps, mais aussi pas mal de compétence ! -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Frédéric Glorieux wrote: http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp() Oops, pas vu, je cherchais le symétrique à Resource.getLastModificationTime() Comme expliqué précédemment, la granularité est différente, mais c'est vraisemblablment de peu d'importance. De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il faut et, plus souvent, que son rafraîchissement n'est pas toujours correctement répercuté comme il se doit. Tu as une idée des risques encourus ? Des configs non prises en compte : un cas *très* particulier (hélas, sinon le problème aurait été reglé depuis longtemps). Un problème potentiel de verrouillage également, rencontré de façon *très* épisodique (mais qui pourrait flinguer la db) : il faudra bien le régler un jour. Non, le plus gros problème de ce cache... c'est quand il a beaucoup d'entrées (i.e. de collections), surtout quand il faut les partager à plusieurs :-) Le genre d'opérations qu'il faudrait faire suivre d'un nettoyage du cache pour avoir plus d'assurance ? Le cache n'est pas disponible de l'extérieur. En ce qui concerne la source Cocoon et sans vouloir rallumer la polémique sur les licences qui a meublé les premiers jours de cette liste, vous savez où il faut envoyer les patches :-) Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir, mais cela ne fait pas des millions de lignes. Dépose le sur la mailing-list ou,mieux sur la page Sourceforge du projet. En ce qui concerne les autres aspects de développements d'Exist, je comprends cet appel aux bonnes volontés, mais le défi est dur à relever. Il faut non seulement du temps, mais aussi pas mal de compétence ! Comme dans tout projet, tout est bon à prendre : doc, traductions, reviewing, support technique, test cases (du Java assez simple en général)... Sinon, il y a toujours l'appli Armageddon à réaliser : monter la XQueryTestSuite sur eXist :-) A+ p.b. - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: XMLDBSource, cacheable + questions
Tu as une idée des risques encourus ? Des configs non prises en compte : un cas *très* particulier (hélas, sinon le problème aurait été reglé depuis longtemps). Un problème potentiel de verrouillage également, rencontré de façon *très* épisodique (mais qui pourrait flinguer la db) : il faudra bien le régler un jour. Non, le plus gros problème de ce cache... c'est quand il a beaucoup d'entrées (i.e. de collections), J'ai vu :o) surtout quand il faut les partager à plusieurs :-) OK, donc globalement, la date est bonne, au pire, c'est Exist qui est flingué, mais en ce cas, la cache cocoon peut faire illusion et sauver la réponse au public ? Le genre d'opérations qu'il faudrait faire suivre d'un nettoyage du cache pour avoir plus d'assurance ? Le cache n'est pas disponible de l'extérieur. Je veux dire la cache Cocoon, quand elle commence à garder des mauvaises entrées ? Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir, mais cela ne fait pas des millions de lignes. Dépose le sur la mailing-list ou,mieux sur la page Sourceforge du projet. Pour le peu de lignes que cela représente, j'ai honte d'en faire un pataques. Poster les lignes me coûtent peu, les garantir et les tester dans le contexte de votre appli Cocoon, c'est plus long. Comme dans tout projet, tout est bon à prendre : doc, traductions, reviewing, support technique, test cases (du Java assez simple en général)... Sinon, il y a toujours l'appli Armageddon à réaliser : monter la XQueryTestSuite sur eXist :-) Que les cocooneux utilisateurs d'Exist t'entendent. -- Frédéric Glorieux (AJLSM, http://ajlsm.com) - Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
Re: Two XML files and one XSL file in Cocoon(Summary)
On a side note, which logkit logger do I have to enable if I want to see all caching activity from Cocoon ? I'm afraid some of my pipelines are still quite slow even with type=caching enabled, and I'd like to see what's going on behind the scene. Tried to use the profiling pipelines? (type=profile-caching or type=profile-noncaching) Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: capturing XML in forms
* Andre Juffer: Capturing XHTML content via forms is something I have never done before (and is of course not specific to Cocoon). Basically, I guess, one would have to parse the text and store the result for instance in a DOM document which is subsequently stored in the XML database, right? Or is there is more simple or better solution, maybe cocoon can handle this already? Integrated in Cocoon there is the htmlarea styling that displays the HTMLArea editor, and the htmlarea convertor in forms to convert the text typed by the user to XHTML. This is very similar to what you intend to do, especially the convertor stuff. See the HTMLArea forms samples at http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/htmlarea -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: capturing XML in forms
Jean-Baptiste Quenot wrote: * Andre Juffer: Capturing XHTML content via forms is something I have never done before (and is of course not specific to Cocoon). Basically, I guess, one would have to parse the text and store the result for instance in a DOM document which is subsequently stored in the XML database, right? Or is there is more simple or better solution, maybe cocoon can handle this already? Integrated in Cocoon there is the htmlarea styling that displays the HTMLArea editor, and the htmlarea convertor in forms to convert the text typed by the user to XHTML. This is very similar to what you intend to do, especially the convertor stuff. See the HTMLArea forms samples at http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/htmlarea This looks very similar to the one that I currently use, Xinha: http://xinha.gogo.co.nz/xinha-nightly/examples/full_example-body.html As far as I could see this editor produces valid XHTML. That is, after capturing the textarea content, I actually replace all lt; and gt; by a '' and '' and put that in a java.lang.String containing also the ?xml version=1.0 ? and use a SAX parser to parse this String (place it into a StringReader first). It appears entirely valid. It should then be straightword to create a DOM document with cocoon's org.apache.cocoon.xml.dom.DOMBuilder and place this Document into the Session and ultimately it can be inserted into the pipeline with the Read DOM Session Transformer (I have not tried this part yet). I'll have a look at HTMLArea forms samples. Thanks. Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: capturing XML in forms
See http://xinha.python-hosting.com/ for the reason why HTMLArea and Xinha are look-alikes Jean-Baptiste Quenot wrote: * Andre Juffer: Capturing XHTML content via forms is something I have never done before (and is of course not specific to Cocoon). Basically, I guess, one would have to parse the text and store the result for instance in a DOM document which is subsequently stored in the XML database, right? Or is there is more simple or better solution, maybe cocoon can handle this already? Integrated in Cocoon there is the htmlarea styling that displays the HTMLArea editor, and the htmlarea convertor in forms to convert the text typed by the user to XHTML. This is very similar to what you intend to do, especially the convertor stuff. See the HTMLArea forms samples at http://cocoon.zones.apache.org/demos/release/samples/blocks/fo rms/htmlarea This looks very similar to the one that I currently use, Xinha: http://xinha.gogo.co.nz/xinha-nightly/examples/full_example-body.html As far as I could see this editor produces valid XHTML. That is, after capturing the textarea content, I actually replace all lt; and gt; by a '' and '' and put that in a java.lang.String containing also the ?xml version=1.0 ? and use a SAX parser to parse this String (place it into a StringReader first). It appears entirely valid. It should then be straightword to create a DOM document with cocoon's org.apache.cocoon.xml.dom.DOMBuilder and place this Document into the Session and ultimately it can be inserted into the pipeline with the Read DOM Session Transformer (I have not tried this part yet). I'll have a look at HTMLArea forms samples. Thanks. Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Two XML files and one XSL file in Cocoon(Summary)
No, as aggregation, just as every other pipeline construct, uses the cache system. So the slowness should come from other parts of the pipeline. On a side note, which logkit logger do I have to enable if I want to see all caching activity from Cocoon ? I'm afraid some of my pipelines are still quite slow even with type=caching enabled, and I'd like to see what's going on behind the scene. I think you'll need !-- Cocoon cache and stores logger -- category log-level=WARN name=store category log-level=WARN name=janitor log-target id-ref=core/ log-target id-ref=error/ /category log-target id-ref=core/ log-target id-ref=error/ /category Thanks Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Increasing Cocoon Portal speed at stat-up
* Angelo Immediata: ... so that i can load only one time the layout and use always them without to call getDefaultLayout at every new request? If i can do this... can you suggest how i can operate this change? Now the loading of profiles can be cached: See Speedup portal loading http://issues.apache.org/jira/browse/COCOON-1709 Enjoy, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: force cocoon to reload web.xml and cocoon.xconf
* mgo: Can I force cocoon to reload this two files from perhaps another servlet or anything similar? At the moment it is necessary to restart whole tomcat. Try this URL: http://yourwebapp/?cocoon-reload=1 allow-reload init parameter must be set to true in web.xml for this to work. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Search problem
Hi!
I indexed my site with LuceneIndexTransformer. I got some
content in the .cfs file (aprox. 45 kB).
When I access my search pipeline:
!-- SEARCHING --
map:match
pattern=content/*/*/*/search
map:generate
type=search
map:parameter
name=query value={request-param:search-query}/
/map:generate
map:serialize
type=xml/
/map:match
!-- END
SEARCHING --
all I get is the following xml:
search:results xmlns:search=http://apache.org/cocoon/search/1.0 xmlns:xlink=http://www.w3.org/1999/xlink date=1135263424921 start-index=0 page-length=10/
so no results found. This is very strange since I
tried to search everything possible that I indexed in the first place (words
from lucene:document elements).
Does anybody know why this could happen?
Thanks!
Dan
Re: Search problem
Le 22 déc. 05, à 16:03, Dan Nicolici a écrit : I indexed my site with LuceneIndexTransformer. I got some content in the .cfs file (aprox. 45 kB)... You should be able to verify your index with a tool Luke [1], to make sure it actually contains what you think. -Bertrand [1] http://www.getopt.org/luke/ smime.p7s Description: S/MIME cryptographic signature
Null pointer at cocoon.redirect
Hi all.
I have pubclication in lenya and i have to use CForms there. I decided
to add such pipeline:
map:match pattern=**/forms/*.xml
map:select type=request-parameter
map:parameter name=parameter-name value=continuation-id/
map:when test=
map:call function={2}_form
map:parameter name=language value=en /
/map:call
/map:when
map:otherwise
map:call continuation={request-param:continuation-id}/
/map:otherwise
/map:select
/map:match
That pipeline returns a chunk of XHTML with form, that can be inserted
in any document.
When i need to insert form in my document, i use
ss:insert-form src=cocoon:/live/forms/register.xml/
in a document, and in page2xhtml.xsl file, that is applyed do every
document, i have such template:
xsl:template match=ss:insert-form
xsl:variable name=requestString
xsl:for-each select=//xhtml:div
[EMAIL PROTECTED]'request']/h:requestParameters/*
xsl:value-of select=concat('amp;', @name, '=', h:value)/
/xsl:for-each
xsl:choose
xsl:when test=//xhtml:div
[EMAIL PROTECTED]'request']/h:requestParameters/h:[EMAIL
PROTECTED]'continuation-
id']/
xsl:otherwiseamp;continuation-id=/xsl:otherwise
/xsl:choose
/xsl:variable
xsl:variable name=articles select=concat(@src, '?',
$requestString)/
xsl:copy-of select=document($articles)/
/xsl:template
In few words, it generates sms like cocoon:/live/forms/register.xml?
continuation-id= or cocoon:/live/forms/register.xml?continuation-
id=324khhjh23jh4hgjkfhgj3hjname=name1password=password1 and pastes
document($url) (which, actually is a chunk of XHTML with form) in the
document.
Everything goes fine (i mean it works and forms are validated) until i
add cocoon.redirect to my flow that shows a form:
function register_form() {
var form = new Form(resources/misc/forms/register.xml);
var data = new Object();
form.showForm(live/templates/ + cocoon.parameters[language]
+/register.xml, data);
var model = form.getModel();
cocoon.redirectTo(register.html);
}
in a redirect stage cocoon seems to fall at some kind of endless
recursion(or loop), eats all CPU time and RAM. When i break it, it shows
very long stacktrace, i put here only begin of it:
java.lang.NullPointerException
at org.apache.cocoon.components.CocoonComponentManager.release
(CocoonComponentManager.java:548)
at org.apache.cocoon.environment.AbstractEnvironment.release
(AbstractEnvironment.java:565)
at
org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release
(MutableEnvironmentFacade.java:308)
at org.apache.cocoon.sitemap.ContentAggregator.recycle
(ContentAggregator.java:274)
at
org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put
(InstrumentedResourceLimitingPool.java:407)
at
org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut
(PoolableComponentHandler.java:212)
at org.apache.avalon.excalibur.component.ComponentHandler.put
(ComponentHandler.java:425)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release
(ExcaliburComponentSelector.java:307)
at
org.apache.cocoon.components.ExtendedComponentSelector.release
(ExtendedComponentSelector.java:300)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle
(AbstractProcessingPipeline.java:720)
at
org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:77)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:993)
at
org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put
(InstrumentedResourceLimitingPool.java:407)
at
org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut
(PoolableComponentHandler.java:212)
at org.apache.avalon.excalibur.component.ComponentHandler.put
(ComponentHandler.java:425)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release
(ExcaliburComponentSelector.java:307)
at
org.apache.cocoon.components.ExtendedComponentSelector.release
(ExtendedComponentSelector.java:300)
at
org.apache.cocoon.components.EnvironmentDescription.removeFromAutoRelease(CocoonComponentManager.java:783)
at
org.apache.cocoon.components.CocoonComponentManager.removeFromAutomaticRelease(CocoonComponentManager.java:486)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.release
(AbstractProcessingPipeline.java:184)
at org.apache.cocoon.components.source.impl.SitemapSource.reset
(SitemapSource.java:433)
at org.apache.cocoon.components.source.impl.SitemapSource.init
(SitemapSource.java:377)
at
org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:213)
at
org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource
(SitemapSourceFactory.java:64)
at
continuation expiry
Hi, I have an Upload Portal to exchange files with our customers. The portal uses javaflow. In some cases we have quite big files to transfer. So some transfers take more than 10 Minutes. In those situations, the user gets an continuation invalid error, instead of the next page sent by the sendPage() method from the java flow. When i check the timeToLive() value from the WebContinuation i always get the value 60. I think this value is in miliseconds. So the duration seems to be 10 minutes. I already raised the time-to-live to 100 hours, but the value from the WebContinuation.TimeToLive() does not change. What did I wrong? Any hints? Thanks, Michel This is a snippet from my cocoon.xconf: continuations-manager continuation-sharing-bug-compatible=false logger=flo w.manager session-bound-continuations=false time-to-live=36000 expirations-check type=periodic offset18/offset period180/period /expirations-check /continuations-manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuation expiry
You might want to check out this thread: http://thread.gmane.org/gmane.text.xml.cocoon.devel/55453 In short, JavaInterpreter uses a hard-coded, non-configurable value of 60 for continuation time to live. You'll have to write your own configurable flow interpreter and replace the default in cocoon.xconf. On 12/22/05, Michael Ebert [EMAIL PROTECTED] wrote: Hi, I have an Upload Portal to exchange files with our customers. The portal uses javaflow. In some cases we have quite big files to transfer. So some transfers take more than 10 Minutes. In those situations, the user gets an continuation invalid error, instead of the next page sent by the sendPage() method from the java flow. When i check the timeToLive() value from the WebContinuation i always get the value 60. I think this value is in miliseconds. So the duration seems to be 10 minutes. I already raised the time-to-live to 100 hours, but the value from the WebContinuation.TimeToLive() does not change. What did I wrong? Any hints? Thanks, Michel This is a snippet from my cocoon.xconf: continuations-manager continuation-sharing-bug-compatible=false logger=flo w.manager session-bound-continuations=false time-to-live=36000 expirations-check type=periodic offset18/offset period180/period /expirations-check /continuations-manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kris Schneider mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question About Generators Getting Called Twice
I am just playing around with Cocoon, both with XSP and writing my own custom generator. I just observed that it seems like Generators are getting called twice with the same instance of the Object. This was observed by throwing some System.err.println in my XSP, and by writing a simple generator that output messages to the log in the recycle(), generate(), and setup() methods. Is this intended/common behavior for Cocoon to run through a Generator twice or is my configuration not quite right? Cocoon 2.1.8 JDK 1.4 Mac OS X Tiger __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SOLVED] RE: JMS Listener invokes Cocoon pipeline (RE: How do I create a context from a background task in cocoon?)
Turns out the memory problem was caused by a special transformer
component we were using, not anything to do with BackgroundEnvironment.
However, it's still worth noting that the api for background Cocoon
processing isn't very pretty, imho. I've currently actually got the JMS
listener making an http request to localhost, rather than use
BackgroundEnvironment. It's a bit of a strange way to go about it
though, I know. But I'd rather not try and manage my on Cocoon
environment to this detail.
Cheers all, merry Christmas,
Ollie
-Original Message-
From: Ard Schrijvers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 20 December 2005 4:17 a.m.
To: users@cocoon.apache.org
Subject: RE: JMS Listener invokes Cocoon pipeline (RE: How do I create a
context from a background task in cocoon?)
Hi, I eventually also got it running with a BackgroundEnvironment. I
have not yet experienced the java.lang.OutOfMemory but this may merely
be a result that it is not yet in production. At least I know to test it
now :-)
The way it now works for me, is to create a BackgroundEnvironment, then
lookup a SourceResolver, and use resolveUri.
Probably, at the end, your also nicely releasing your evironment??
CocoonComponentManager.leaveEnvironment();
CocoonComponentManager.endProcessing(env, key); if (processor != null) {
manager.release(processor);
}
And indeed, I don't want to use cron job this either (think I even
needen the quartz block). It seems to me it is way to hard to do
something with for example a class that acts on a JMS message and wants
to process a pipeline.
AS
Hi, we've got a similar need to invoke Cocoon in the background:
We have a JMS Listener component configured to startup when Cocoon
starts up (in cocoon.xconf). When its asynch onMessage() method is
called, we want the method to then invoke a Cocoon pipeline. We expect
the JMS topic to be pushing a steady, reasonably constant supply of
messages every few seconds or less, sometimes there will be spikes.
What is the best way to implement this?
Our current implementation uses the BackgroundEnvironment class from
the cron block that Sylvain Wallez mentions below. Unfortunately
however, under our soak test the server collapses after 24 hours with
a java.lang.OutOfMemory error.
One thing I can see I've probably done wrong is I fully establish the
Cocoon environment entirely within the onMessage() method, every time.
That's a lot of work to do for EVERY message we get. So should I
instead establish the BackgroundEnvironment (and lookup the
SourceResolver) on initialisation of the Listener component? Then the
only work performed within onMessage is to call
SourceResolver.resolveURI()?
If so, exactly how much setup should I do in initialise()? Is it ok if
it goes as far as:
...
CocoonComponentManager.enterEnvironment(env, new
WrapperComponentManager(this.manager), processor); this.resolver =
(SourceResolver) this.manager.lookup(SourceResolver.ROLE);
Then in onMessage() I can simply call: src =
this.resolver.resolveURI(uri);
At what point should I close down and clean up the
BackgroudEnvironment?
In dispose()?
I'm a bit nervous using BackgroundEnvironment and
CocoonComponentManager in this way - especially when the
CocoonComponentManager javadoc says
'WARNING: This is a private Cocoon core class - do NOT use this
class directly'! I'm tempted to instead have the onMessage() method
simply make an http request to the proper Cocoon environment on
localhost:8080. It feels like it would be the safer way to go. Then I
can let the normal CocoonServlet look after the environment.
(Also note,
I'd rather not use the cron block).
Any advice? Thanks in advance,
Oliver Powell
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 7 December 2005 10:26 a.m.
To: users@cocoon.apache.org
Subject: Re: How do I create a context from a background task in
cocoon?
Ard Schrijvers wrote:
Does anybody have experience with calling a pipeline from a
background
task resulting from an eventHandler?
So, on an event, a java class is executed which implements
Contextualizable.
I am trying something like
import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.context.Context;
import org.apache.avalon.framework.context.ContextException;
implements Contextualizable, ...
private Context context;
public void contextualize(Context context) throws
ContextException
{
this.context = context;
}
PipelineUtil pipeUtil = new PipelineUtil(); try {
pipeUtil.contextualize(context);
pipeUtil.service(serviceManager);
pipeUtil.processToSAX(uri, null, somehandler); } catch
(Exception
e) {
throw new CascadingRuntimeException(Cannot process
pipeline from
' + uri + ', e); } finally {
pipeUtil.dispose();
}
Now, this does not work, because it does not have a
Compiling problems 2.2 with Eclipse
Hi, I downloaded a svn version of the trunk 2-3 days ago and started to compile it the usual way (build.bat then cocoon.bat servlet) : everything works like a charm. When I start to compile it with eclipse, I have errors in session-fw about SessionManager not found in the project. If I just touch the source files that have problem in the session-fw block, the files compile !!! So I finally end with a cocoon compiled. Then I start cocoon servlet and errors appear : * my WEB-INF/lib is empty and I'm using the CocoonServlet in web.xml, it does not find the org/apache/common/langs/exception/NestableException * if I had the common-lang.jar in the endorsed lib, I have another error about excalibur Then I put all the libs I have in the optional lib directory in the WEB-INF/lib and I use ParanoidCocoonServlet. I can see all the libs loading, and I finish with an error about the ParanoidServlet that can't be initialized Any ideas ? -- BlueXML Jean-Christophe Kermagoret Directeur associé [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing user agent within XSLT
Hi, Is it possible to access either request headers or the browser selector from within an XSLT template? I want to all pages sent to MSIE to differ slightly from all pages sent to Mozilla/Netscape, and because I'm using a lot of pipelines, using a when/otherwise structure in every pipeline in my sitemap (which is the only way I know how to do it) would be extremely unwieldy. For example, I would like to do this: xsl:when $useragent = 'explorer' Crazy Explorer workaround /xsl:when xsl:otherwise Code according to W3C standard /xsl:otherwise Thanks, Joe Hill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cforms + htmlarea, how to fix html?
Hello,
I'm using cforms and in there I have htmlarea. I have tried this way:
cocoon.procesPipelineTo(html2xml,{},output);
map:match pattern=html2xml
map:generate type=html
map:parameter name=form-name value=content /
/map:generate
map:serialize type=xml /
/map:match
This solution works like 99% of the time.. Problems come when I use
Ä Ö or Å character (problem not present with äöå). problem also is
present with that word-style - sign, which is more larger and prob.
with more characters.. It encodes those to entities, but like this:
#123; .. so data what is saved to DB has entities and I don't want to
have entities there. Encoding is utf-8 so encoding isn't needed.
I also tried htmlcleaner convertor, but it destroys way too much data
(and I have tried to configure it).. Like:
div style=...
p
foo
/p
br /br /
p
bar
/p
/div
translates to -
pfoo/p
pbar/p
which is not nice.
I like htmlcleaner solution better than processpipeline thingie, but,
unfortunally it destroys too much data.
So, help needed =)
Thanks and merry christmas to those who celibrate it, Joose
--
Always remember that you are unique, just like everyone else!
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing user agent within XSLT
You will have to pass the user agent information on from the sitemap to your xslt stylesheet, something like: map:transform src=path_to_xsl map:parameter name=user-agent value=... / /map:transform and in your xsl: xsl:param name=user-agent select='msie' / !-- note: 'msie' is the default -- How to access the user agent info? I am pretty sure you can get to it using the request input module. But perhaps someone can confirm? Regards, Geert Joseph Hill wrote: Hi, Is it possible to access either request headers or the browser selector from within an XSLT template? I want to all pages sent to MSIE to differ slightly from all pages sent to Mozilla/Netscape, and because I'm using a lot of pipelines, using a when/otherwise structure in every pipeline in my sitemap (which is the only way I know how to do it) would be extremely unwieldy. For example, I would like to do this: xsl:when $useragent = 'explorer' Crazy Explorer workaround /xsl:when xsl:otherwise Code according to W3C standard /xsl:otherwise Thanks, Joe Hill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
