2 Apr
2008
2 Apr
'08
10:47 a.m.
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