Re: [xwiki-devs] XEclipse - problem connecting to local XWiki
I did a bit of debugging and traced the problem to line 65 in XWikiRemoteDAO.java try { Page page = swizzleXWiki.getPage("XWiki.WebHome"); } catch (ClassCastException e) { ... } catch (Exception e) { The date is was earlier complaining about is the modification date of the wiki space I believe. Seems like there is a SwizzleConversionException thrown which the workaround mentioned in the comments fails to catch and I think the ClassCastException there was actually supposed to be a SwizzleConversionException so I changed the code to: try { Page page = swizzleXWiki.getPage("XWiki.WebHome"); } catch (SwizzleConversionException e) { Now, it disables the conversion as the workaround says but now I`m getting this exception: org.xwiki.eclipse.model.XWikiConnectionException: org.xwiki.eclipse.model.impl.XWikiDAOException: org.codehaus.swizzle.confluence.ConfluenceException: Null values aren't supported, if isEnabledForExtensions() == false at org.xwiki.eclipse.model.impl.XWikiPlainConnection.connect(XWikiPlainConnection.java:83) at org.xwiki.eclipse.XWikiEclipsePageIndexer$IndexerJob.run(XWikiEclipsePageIndexer.java:67) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.xwiki.eclipse.model.impl.XWikiDAOException: org.codehaus.swizzle.confluence.ConfluenceException: Null values aren't supported, if isEnabledForExtensions() == false at org.xwiki.eclipse.model.impl.XWikiRemoteDAO.<init>(XWikiRemoteDAO.java:79) at org.xwiki.eclipse.model.impl.XWikiPlainConnection.connect(XWikiPlainConnection.java:71) ... 2 more Caused by: org.codehaus.swizzle.confluence.ConfluenceException: Null values aren't supported, if isEnabledForExtensions() == false at org.codehaus.swizzle.confluence.Confluence.call(Confluence.java:778) at org.codehaus.swizzle.confluence.Confluence.call(Confluence.java:751) at org.codehaus.swizzle.confluence.Confluence.login(Confluence.java:49) at org.xwiki.eclipse.model.impl.XWikiRemoteDAO.<init>(XWikiRemoteDAO.java:54) ... 3 more 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 :) ----- Original Message ---- From: Enygma <[email protected]> To: [email protected] Cc: [email protected] Sent: Tuesday, April 1, 2008 2:23:13 AM Subject: [xwiki-devs] XEclipse - problem connecting to local XWiki Hello XWiki users and developers. My name is Eduard Moraru and I'm going to apply this year for Google Summer of Code at XWiki on the project XWiki Offline. I am planning on embedding this project in the already existing XEclipse on which I've understood there is already some work done. My problem is that I tried out XEclipse (xwiki-eclipse-rcp-linux-gtk-x86-1.1.zip and xwiki-eclipse-1.1.zip) on a local installation of XWiki (xwiki-enterprise-installer-generic-1.3.jar) using both user Admin and a new test user and did not manage to connect to the wiki. I then tried to connect to xwiki.org using a newly registered account and it worked perfectly. On the local installation, XEclipse pops an exception which I can't get past: org.xwiki.eclipse.model.XWikiConnectionException:org.xwiki.eclipse.model.impl.XWikiDAOException:org.codehaus.swizzle.confluence.SwizzleConversionException:java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54EEST 2007" at org.xwiki.eclipse.model.impl.XWikiPlainConnection.connect(Unknown Source) at org.xwiki.eclipse.wizards.NewConnectionWizard$1.run(Unknown Source) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) Caused by: org.xwiki.eclipse.model.impl.XWikiDAOException:org.codehaus.swizzle.confluence.SwizzleConversionException:java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54EEST 2007" at org.xwiki.eclipse.model.impl.XWikiRemoteDAO.<init>(Unknown Source) ... 3 more Caused by: org.codehaus.swizzle.confluence.SwizzleConversionException:java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54EEST 2007" at org.codehaus.swizzle.confluence.ConfluenceObjectConvertor.revert(ConfluenceObjectConvertor.java:56) at org.codehaus.swizzle.confluence.MapConvertor.revert(MapConvertor.java:39) at org.codehaus.swizzle.confluence.Confluence.revert(Confluence.java:791) at org.codehaus.swizzle.confluence.Confluence.getPage(Confluence.java:127) ... 4 more Caused by: java.text.ParseException: Unparseable date: "mer. juil. 11 18:57:54 EEST 2007" at java.text.DateFormat.parse(DateFormat.java:355) at org.codehaus.swizzle.confluence.ConfluenceObjectConvertor.revert(ConfluenceObjectConvertor.java:53) ... 7 more I also posted a bug on JIRA at http://jira.xwiki.org/jira/browse/XECLIPSE-100 regarding this issue but I figured on the mailing list I'd get faster feedback. My question is: Am I doing something wrong with my local installation? Are there some other privileges to give that I left out? At a first look, I`d say It`s a hardcoded date "mer. juil. 11 18:57:54 EEST 2007"(it's always the same), left there during development, but I`m not sure if it`s on the XEclipse side or the XWiki side. Thank you very much for your time and I await your suggestions. ____________________________________________________________________________________ No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends. http://tc.deals.yahoo.com/tc/blockbuster/text1.com _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com
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
participants (2)
-
Enygma -
Fabio Mancinelli