- Wikitty-devel - mailman.cloud.codelutin.com

Re: [Wikitty-devel] [Wikitty-commits] r858 - in trunk/wikitty-publication: . src/main/java/org/nuiton/wikitty/publication src/main/resources src/main/webapp src/main/webapp/WEB-INF
by Eric Chatellier May 5, 2011

May 5, 2011

Le 05/05/2011 11:55, mfortun(a)users.nuiton.org a écrit : > Added: trunk/wikitty-publication/src/main/webapp/WEB-INF/sitemesh.xml > =================================================================== > --- trunk/wikitty-publication/src/main/webapp/WEB-INF/sitemesh.xml (rev 0) > +++ trunk/wikitty-publication/src/main/webapp/WEB-INF/sitemesh.xml 2011-05-05 09:55:52 UTC (rev 858) > @@ -0,0 +1,52 @@ > +<?xml version="1.0" encoding="UTF-8" ?> > + > + > + Je pense que c'est le fichier par défaut, il n'est pas nécessaire de le copier coller. > > -<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http:/java.sun.com/dtd/web-app_2_3.dtd"> > +<web-app id="wikitty-publication" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http:/java.sun.com/dtd/web-app_2_3.dtd"> Tu peut passer en 2.5. > + > + > + <context-param> > + <param-name>contextConfigLocation</param-name> > + <param-value>classpath*:applicationContext*.xml</param-value> > + </context-param> Spring (inutile) > +  > + <servlet> > + <servlet-name>jspSupportServlet</servlet-name> > + <servlet-class>org.apache.struts2.views.JspSupportServlet</servlet-class> > + <load-on-startup>5</load-on-startup> > + </servlet> Inutile (sauf si tu en trouve l'utilité ;-)) > + <jsp-config> > + <jsp-property-group> > + <url-pattern>*.jsp</url-pattern> > + <trim-directive-whitespaces>true</trim-directive-whitespaces> > + </jsp-property-group> > + </jsp-config> Je me demande a quoi ca sert également. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

Editeur de code web pour WikittyPublication
by Benjamin POUSSIN May 4, 2011

May 4, 2011

Salut, Pour wikitty publication pour aider l'utilisateur a modifier les scripts en mode web, il serait bien d'utiliser le projet http://codemirror.net/ ou un autre similaire s'il y a mieux -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 1

Specs pour la partie site-publication de wikitty publication
by Manoël Fortun May 2, 2011

May 2, 2011

Bonjour, Voici les specs pour la partie site publication de wikitty publication. Specs pour : -gestion login/logout -gestion des droits -multicontexte pour les données Manoël.

1 0

probleme de connexion postgresql et de tx
by Benjamin POUSSIN April 29, 2011

April 29, 2011

Salut, Lors de la mise en place de bow 0.5 on est tombé sur une erreur avec postgresql/dbcp. En gros le pool ferme la connexion puis l'enleve de son cache (WeakHashMap) or, pour cela il a besoin de calculer le hashCode de la connexion fermée qui contient alors null. Donc forcement on avait un NPE :(. En changeant le driver jdbc et en prenant le dernier (9.0) le probleme est résolu. Mais ensuite il y avait des problemes d'autocommit qui n'etait pas a true (jamais detecté avec h2 qui doit sans doute par defaut donner des connexions avec autocommit false) En forceant dans la config le autocommit a false wikitty.storage.jdbc.xadatasource.org.postgresql.xa.PGXADataSource.defaultAutoCommit=false ca va mieux, mais j'en ai profite pour corriger dans wikitty pour qu'on check bien qu'on travail avec des connexion autocommit=false pour pouvoir faire des commit On va plus loin, mais on a encore une erreur :( Caused by: java.sql.SQLException: Connection does not have a registered XAResource jdbc:postgresql://localhost/bow?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&loglevel=0&tcpkeepalive=false, UserName=dbuser, PostgreSQL Native Driver at org.apache.commons.dbcp.managed.TransactionRegistry.getXAResource(TransactionRegistry.java:78) at org.apache.commons.dbcp.managed.TransactionContext.setSharedConnection(TransactionContext.java:88) at org.apache.commons.dbcp.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:131) at org.apache.commons.dbcp.managed.ManagedConnection.<init>(ManagedConnection.java:55) at org.apache.commons.dbcp.managed.ManagedDataSource.getConnection(ManagedDataSource.java:77) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) at org.nuiton.wikitty.jdbc.WikittyJDBCUtil.getConnection(WikittyJDBCUtil.java:299) Si on met le XAResource a null, bow refonctionne, mais le probleme est qu'il y a une valeur par defaut et qu'avec un fichier de config on peut pas mettre la valeur a null, mais a vide au mieux, et la encore il y a un bug dans wikitty (que j'ai corrigé) qui ne prenait pas en compte le vide :(. Donc avec la version actuelle stable de wikitty et bow ca ne pourra pas fonctionner avec postgresql. Et de toute facon il faut encore chercher le probleme de XAResource :( Je met en place, une version snapshot, en attendant de corriger le probleme pour que le service ne soit pas interrompu trop longtemps -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

1 1

Nouvelles specs pour wikitty publication sync
by Manoël April 29, 2011

April 29, 2011

Bonjour, Voici les changements dans les specs en considérant que maintenant il n'y a plus qu'une seule opération de synchronisation entre différents service de wikitty. Il y aura je pense à rajouter des choses dans la définition du wikitty service file system. Manoël.

3 7

[ANN] - Wikitty 3.1 released
by nuiton.org Release Notification April 27, 2011

April 27, 2011

1 0

Regression SolR, passage des tests echoues :(
by Benjamin POUSSIN April 14, 2011

April 14, 2011

Salut, Il y a des erreurs (sans doute depuis le changement de version de solr). On avait eu les memes avec l'ancienne version. J'avais regler le probleme. En gros, on est en RAM, mais il creer tout de meme des fichiers (c mal) et du coup, il ne trouve pas ce qu'il lui faut vu qu'il est en RAM. Le probleme, est qu'en RAM, il ne devrait y avoir aucun repertoire et aucun fichier de lu/ecrit. 11/04/13 19:01:24 ERROR core.SolrCore: java.io.FileNotFoundException: segments_en at org.apache.lucene.store.RAMDirectory.openInput(RAMDirectory.java:213) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:253) at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:350) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:736) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346) at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1126) at org.apache.solr.update.SolrIndexWriter.<init>(SolrIndexWriter.java:83) at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:102) at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:174) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:222) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:140) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:64) at org.nuiton.wikitty.storage.solr.SolrServerTest$ThreadAddDocument.run(SolrServerTest.java:89) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 2

[ANN] - Wikitty 3.0.5 released
by nuiton.org Release Notification April 12, 2011

April 12, 2011

1 0

Probleme de deploiement de la derniere release ?
by Benjamin POUSSIN April 11, 2011

April 11, 2011

Salut, Petit problème lors de l'utilisation de la version 3.0.5, j'ai l'impression qu'il n'y a pas eu le pom de jdbc de déposé ? Au plutot certain module n'ont pas ete deployer, le dernier semble etre solr :( """ Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… (8 KB at 59.0 KB/sec) Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/3.0.… Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/3.0.… (17 KB at 22.9 KB/sec) Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… [WARNING] The POM for org.nuiton.wikitty:wikitty-jdbc-impl:jar:3.0.5 is missing, no dependency information available Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… (3 KB at 19.5 KB/sec) [WARNING] The POM for woodstox:wstx-asl:jar:3.2.7 is missing, no dependency information available Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/nuiton-utils… Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… Downloading: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… (56 KB at 181.2 KB/sec) Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/nuiton-utils… (212 KB at 411.2 KB/sec) Downloaded: http://nexus.nuiton.org/nexus/content/groups/public/org/nuiton/wikitty/wiki… (298 KB at 485.8 KB/sec) [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] chorem ............................................ SUCCESS [9.940s] [INFO] Chorem entities ................................... FAILURE [3.347s] [INFO] Chorem web ........................................ SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 14.805s [INFO] Finished at: Mon Apr 11 19:52:44 CEST 2011 [INFO] Final Memory: 11M/133M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project chorem-entities: Could not resolve dependencies for project org.chorem.chorem:chorem-entities:jar:0.1-SNAPSHOT: Could not find artifact org.nuiton.wikitty:wikitty-jdbc-impl:jar:3.0.5 in nexus (http://nexus.nuiton.org/nexus/content/groups/public) -> [Help 1] """ -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

3 2

triggers et champs calculés
by Benjamin POUSSIN April 8, 2011

April 8, 2011

Salut, Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty. J'aime pas trop le terme trigger, ca fait un peu trop BD ;) Je prefere le terme listener sur le WikittyServiceStorage. Les champs calculés =================== les champs calculés seraient ajoutés à la déclaration de l'extension. Il pourrait-être de plusieurs sortes: - request: on indique la requête à jouer pour remplir ce champs avant de retourner l'objet. (Probleme: comment faire avec le cache ? on rejoue ou non la requete, lorsqu'on redonne l'objet provenant du cache ?). Peut-être prévoir une méthode refresh sur le wikitty pour ces champs ? - readonly: les champs existent, mais en lecture seul pour l'utilisateur. les données sont produites et mises en place par un trigger qui les utilises. - java/onStore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du store - java/onRestore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du restore L'idée est que toutes ces types fonctionnent sur la partie api wikitty et non pas sur une implantation specifique (Solr, JDBC, ...) Voyez-vous d'autre type de fonctionnalité possible ? exemple:: Wikitty someobjects [0..*] javaOnStore=org.nuiton.wikitty.Compute Wikitty root readonly=true Wikitty parents [0..*] readonly=true Wikitty tree [0..*] request="TreeNode.name:('toto' OR 'titi')" Faut-il un tag explicite computed=true, ou seulement javaOnStore, request, ... suffisent ? Est-ce que request ne serait pas en fait un javaOnRestore qui aurait un argument qui serait la requête ? Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest(\"TreeNode.name:('toto' OR 'titi')\")" ou Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest javaParam="TreeNode.name:('toto' OR 'titi')" Les trigger/listeners ===================== Les listeners seraient prévenus lors du Store et du Delete. Il y aurait deux types de listener: - les listeners bloquants (qui travail avec le thread d'appel) - les listeners non bloquants qui utilise un thread distinct pour rendre la main rapidement. Pour ajouter l'un ou l'autre sur le WikittyServiceStorage, on utilise les mêmes méthodes, mais les listeners n'implantent pas la même interface. WikittyServiceListener et WikittyServiceThreadedListener. Ces listeners aurait accès au Service constituant le WikittyServiceStorage (storage et indexer). Mais il serai bon, qu'il travail avec l'interface de ces services et ne présume pas de l'implantation (ex: SolR). Il faudra donc potentiellement enrichir l'api pour cela. Par exemple si on souhaite mettre en Listener l'implantation de l'indexation des TreeNode, cela n'est pas vraiment possible actuellement, car trop proche de SolR (Peut-on vraiment faire autrement ?) Je ne pense pas qu'il faille étendre les listeners a tous les WikittyService. Car si l'on souhaite ajouter un traitement lors de l'appel du store sur le WikittyServiceCache, je pense qu'il est préférable de créer un nouveau type de WikittyService que l'on intercalera avant ou après le WikittyCache et on surcharge la méthode store. Ce mécanisme est celui utilisé actuellement pour implanter les fonctionnalités. La différence entre un champs calculé de type java/onStore et un trigger est que le trigger a vision sur tous les objets du store, alors que le champs calculé, ne connait pas les autres objets qui sont en train d'être storé en même temps que lui. De plus, il sont toujours bloquant. Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres - indexation des autorisations pour permettre un check plus rapide et plus simple des droits Vous avez d'autres idées ? Interrogation: je ne sais pas si les listeners non bloquants sont vraiment via (implantable) sans probleme insoluble -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

4 6