[xwiki-devs] XEclipse - problem connecting to local XWiki

[Fabio Mancinelli]

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