On 2 avr. 08, at 04:17, Enygma wrote:
After digging some more, I found out that this is caused by XWikiConnectionManager .getDefault().getPasswordForConnection(connection); at line 67 in XWikiEclipsePageIndexer.java where the connection manager is supposed to get the password associated to the connection but from what I see, the ID of the connection being resolved does not exist in the xwikiConnections HashTable which is, btw, populated with the correct initial connection containing the entered username and password.
I don`t understand where does this second conenction come from that is not listed in the xwikiConnections with its ID, thus returning a null password and generating the above exception upon issuing connect().
Hope this helps on speeding things up.
Thank you and hope someone comes to the rescue :)
Hi Enygma, thanks for your precious input. Two words for explaining the architecture. The indexer listens on events generated by connections through the notification center. Basically every connection generates events like CONNECTION_ESTABLISHED, CONNECTION_CLOSED, etc. When the indexer is started it registers its interest in connection-related events in order to start/stop indexing jobs. The "connection" you are talking about comes from the reception of an event that carries with him the actual connection object that generated that event (i.e., the data parameter of the handleEvent method). So it must be a connection that exists (otherwise the event would not have been generated in the first place). I think this is "the second connection" you were talking about. Actually the indexer uses also a secondary connection in order not to interfere with the "real" one. I had some concurrency issues when both the connection and the indexer used the same "rpc client". In a previous message you also mentioned a date that generated a non- parseable exception concerning a date object... This has to be investigated as well. I will look at the problem for a fix, starting from the information you provided. Anyway a new version of the XMLRPC infrastructure (both server and client side) is almost ready, and this will hopefully solve all the low-level problems. At the application level the indexer is causing more harm than good, so the idea is to provide a server-side search method, and the indexer will be replaced by an XMLRPC call when the information will be actually needed. Thanks again for your help. Cheers, Fabio