This is a serious bug. Thanks for finding it. Apparently the remote-neo jar contains ALL the classes of its dependencies.
My guess is that this problem was introduced in revision 2980 when the packaging changed from jar to bundle. I'll get on to fixing it later today. /Tobias On Tue, Nov 24, 2009 at 7:17 PM, Jakub Kotowski <[email protected]>wrote: > Mattias Persson schrieb: > > Thanks, there seems to be some known problems with lucene on NFS. If > > you're calling getNodes on a non-existing index then I committed a fix > > Yes, it's a getNodes call on non-existing index. > > > for that (added one extra null check), but if that index should exist > > it could just be that lucene is having trouble with NFS. > > > I don't know why there was a difference between NFS and the local drive > but I probably found the cause of the problems. > > I had all the following jars on the classpath: > index-util-0.9-20091120.170916-6.jar > neo-1.0-b11-20091114.181002-8.jar > neo-component-commons-0.3-20090815.173702-1.jar > shell-1.0-b11-20091101.190419-1.jar > remote-neo-0.4-20091101.202529-1.jar > > and LuceneIndexService was apparently loaded from > remote-neo-0.4-20091101.202529-1.jar which contains an older version of > the class. After removing remote-neo, it started to work. > > At one point I also got a ClassNotFound exception which required adding > the neo-component-commons - is it a new dependency? I think I haven't > seen it mentioned in any documentation. > > Cheers, > Jakub > > > > > > I'll look into this further to see if there's something to be done to > > help lucene in these areas. > > > > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Tobias Ivarsson <[email protected]> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
