fieldType:analyzer without class or tokenizer & filter list seems to point to the config - you may want to correct.
On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > Hi, > I checked out modules & lucene from the trunk. > Performed a build using the following commands > ant clean > ant compile > ant example > > Which compiled successfully. > > > I then put my existing index(using schema.xml from solr1.4.0/conf/solr/) in > the multicore folder, configured solr.xml and started the server > > When i type in http://localhost:8983/solr > > i get the following error: > org.apache.solr.common.SolrException: Plugin init failure for [schema.xml] > fieldType:analyzer without class or tokenizer & filter list > at > > org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:168) > at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480) > at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:122) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:429) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:286) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:198) > at > > org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:123) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:86) > at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at > > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:662) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) > at > > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) > at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at > > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) > at > > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at > > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) > at org.mortbay.jetty.Server.doStart(Server.java:224) > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.mortbay.start.Main.invokeMain(Main.java:194) > at org.mortbay.start.Main.start(Main.java:534) > at org.mortbay.start.Main.start(Main.java:441) > at org.mortbay.start.Main.main(Main.java:119) > Caused by: org.apache.solr.common.SolrException: analyzer without class or > tokenizer & filter list > at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:908) > at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:60) > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450) > at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435) > at > > org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:142) > ... 32 more > > > Then i picked up an existing index (schema.xml from solr1.3/solr/conf) and > put it in multicore folder, configured solr.xml and restarted my index > > Collapsing worked fine. > > Any pointers, which part of schema.xml (solr 1.4) is causing this > exception? > > Regards, > Raakhi > > > > On Wed, Jun 23, 2010 at 1:35 PM, Rakhi Khatwani <rkhatw...@gmail.com> > wrote: > > > > > Oops this is probably i didn't checkout the modules file from the trunk. > > doing that right now :) > > > > Regards > > Raakhi > > > > On Wed, Jun 23, 2010 at 1:12 PM, Rakhi Khatwani <rkhatw...@gmail.com > >wrote: > > > >> Hi, > >> Patching did work. but when i build the trunk, i get the > following > >> exception: > >> > >> [SolrTrunk]# ant compile > >> Buildfile: /testWorkspace/SolrTrunk/build.xml > >> > >> init-forrest-entities: > >> [mkdir] Created dir: /testWorkspace/SolrTrunk/build > >> [mkdir] Created dir: /testWorkspace/SolrTrunk/build/web > >> > >> compile-lucene: > >> > >> BUILD FAILED > >> /testWorkspace/SolrTrunk/common-build.xml:207: > >> /testWorkspace/modules/analysis/common does not exist. > >> > >> Regards, > >> Raakhi > >> > >> On Wed, Jun 23, 2010 at 2:39 AM, Martijn v Groningen < > >> martijn.is.h...@gmail.com> wrote: > >> > >>> What exactly did not work? Patching, compiling or running it? > >>> > >>> On 22 June 2010 16:06, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > >>> > Hi, > >>> > I tried checking out the latest code (rev 956715) the patch did > >>> not > >>> > work on it. > >>> > Infact i even tried hunting for the revision mentioned earlier in > this > >>> > thread (i.e. rev 955615) but cannot find it in the repository. (it > has > >>> > revision 955569 followed by revision 955785). > >>> > > >>> > Any pointers?? > >>> > Regards > >>> > Raakhi > >>> > > >>> > On Tue, Jun 22, 2010 at 2:03 AM, Martijn v Groningen < > >>> > martijn.is.h...@gmail.com> wrote: > >>> > > >>> >> Oh in that case is the code stable enough to use it for production? > >>> >> - Well this feature is a patch and I think that says it all. > >>> >> Although bugs are fixed it is deferentially an experimental feature > >>> >> and people should keep that in mind when using one of the patches. > >>> >> Does it support features which solr 1.4 normally supports? > >>> >> - As far as I know yes. > >>> >> > >>> >> am using facets as a workaround but then i am not able to sort on > any > >>> >> other field. is there any workaround to support this feature?? > >>> >> - Maybee http://wiki.apache.org/solr/Deduplication prevents from > >>> >> adding duplicates in you index, but then you miss the collapse > counts > >>> >> and other computed values > >>> >> > >>> >> On 21 June 2010 09:04, Rakhi Khatwani <rkhatw...@gmail.com> wrote: > >>> >> > Hi, > >>> >> > Oh in that case is the code stable enough to use it for > >>> production? > >>> >> > Does it support features which solr 1.4 normally supports? > >>> >> > > >>> >> > I am using facets as a workaround but then i am not able to sort > on > >>> any > >>> >> > other field. is there any workaround to support this feature?? > >>> >> > > >>> >> > Regards, > >>> >> > Raakhi > >>> >> > > >>> >> > On Fri, Jun 18, 2010 at 6:14 PM, Martijn v Groningen < > >>> >> > martijn.is.h...@gmail.com> wrote: > >>> >> > > >>> >> >> Hi Rakhi, > >>> >> >> > >>> >> >> The patch is not compatible with 1.4. If you want to work with > the > >>> >> >> trunk. I'll need to get the src from > >>> >> >> https://svn.apache.org/repos/asf/lucene/dev/trunk/ > >>> >> >> > >>> >> >> Martijn > >>> >> >> > >>> >> >> On 18 June 2010 13:46, Rakhi Khatwani <rkhatw...@gmail.com> > wrote: > >>> >> >> > Hi Moazzam, > >>> >> >> > > >>> >> >> > Where did u get the src code from?? > >>> >> >> > > >>> >> >> > I am downloading it from > >>> >> >> > > https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4 > >>> >> >> > > >>> >> >> > and the latest revision in this location is 955469. > >>> >> >> > > >>> >> >> > so applying the latest patch(dated 17th june 2010) on it still > >>> >> generates > >>> >> >> > errors. > >>> >> >> > > >>> >> >> > Any Pointers? > >>> >> >> > > >>> >> >> > Regards, > >>> >> >> > Raakhi > >>> >> >> > > >>> >> >> > > >>> >> >> > On Fri, Jun 18, 2010 at 1:24 AM, Moazzam Khan < > >>> moazz...@gmail.com> > >>> >> >> wrote: > >>> >> >> > > >>> >> >> >> I knew it wasn't me! :) > >>> >> >> >> > >>> >> >> >> I found the patch just before I read this and applied it to > the > >>> trunk > >>> >> >> >> and it works! > >>> >> >> >> > >>> >> >> >> Thanks Mark and martijn for all your help! > >>> >> >> >> > >>> >> >> >> - Moazzam > >>> >> >> >> > >>> >> >> >> On Thu, Jun 17, 2010 at 2:16 PM, Martijn v Groningen > >>> >> >> >> <martijn.is.h...@gmail.com> wrote: > >>> >> >> >> > I've added a new patch to the issue, so building the trunk > >>> (rev > >>> >> >> >> > 955615) with the latest patch should not be a problem. Due > to > >>> >> recent > >>> >> >> >> > changes in the Lucene trunk the patch was not compatible. > >>> >> >> >> > > >>> >> >> >> > On 17 June 2010 20:20, Erik Hatcher <erik.hatc...@gmail.com > > > >>> >> wrote: > >>> >> >> >> >> > >>> >> >> >> >> On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote: > >>> >> >> >> >>> > >>> >> >> >> >>> p.s. I'd be glad to contribute our Maven build > >>> re-organization > >>> >> back > >>> >> >> to > >>> >> >> >> the > >>> >> >> >> >>> community to get Solr properly Mavenized so that it can be > >>> >> >> distributed > >>> >> >> >> and > >>> >> >> >> >>> released more often. For us the benefit of this structure > >>> is > >>> >> that > >>> >> >> we > >>> >> >> >> will > >>> >> >> >> >>> be able to overlay addons such as RequestHandlers and > other > >>> third > >>> >> >> party > >>> >> >> >> >>> support without having to rebuild Solr from scratch. > >>> >> >> >> >> > >>> >> >> >> >> But you don't have to rebuild Solr from scratch to add a > new > >>> >> request > >>> >> >> >> handler > >>> >> >> >> >> or other plugins - simply compile your custom stuff into a > >>> JAR and > >>> >> >> put > >>> >> >> >> it in > >>> >> >> >> >> <solr-home>/lib (or point to it with <lib> in > >>> solrconfig.xml). > >>> >> >> >> >> > >>> >> >> >> >>> Ideally, a Maven Archetype could be created that would > >>> allow one > >>> >> >> >> rapidly > >>> >> >> >> >>> produce a Solr webapp and fire it up in Jetty in mere > >>> seconds. > >>> >> >> >> >> > >>> >> >> >> >> How's that any different than cd example; java -jar > >>> start.jar? Or > >>> >> do > >>> >> >> >> you > >>> >> >> >> >> mean a Solr client webapp? > >>> >> >> >> >> > >>> >> >> >> >>> Finally, with projects such as Bobo, integration with > Spring > >>> >> would > >>> >> >> make > >>> >> >> >> >>> configuration more consistent and request significantly > less > >>> java > >>> >> >> >> coding > >>> >> >> >> >>> just to add new capabilities everytime someone authors a > new > >>> >> >> >> RequestHandler. > >>> >> >> >> >> > >>> >> >> >> >> It's one line of config to add a new request handler. How > >>> many > >>> >> >> >> ridiculously > >>> >> >> >> >> ugly confusing lines of Spring XML would it take? > >>> >> >> >> >> > >>> >> >> >> >>> The biggest thing I learned about Solr in my work thusfar > >>> is > >>> >> that > >>> >> >> >> patches > >>> >> >> >> >>> like these could be standalone modules in separate > projects > >>> if it > >>> >> >> >> weren't > >>> >> >> >> >>> for having to hack the configuration and solrj methods up > to > >>> >> adopt > >>> >> >> >> them. > >>> >> >> >> >>> Which brings me to SolrJ, great API if it would stay > >>> generic and > >>> >> >> have > >>> >> >> >> less > >>> >> >> >> >>> concern for adding method each time some custom > collections > >>> and > >>> >> >> query > >>> >> >> >> >>> support for morelikethis or collapseddocs needs to be > added. > >>> >> >> >> >> > >>> >> >> >> >> I personally find it silly that we customize SolrJ for all > >>> these > >>> >> >> request > >>> >> >> >> >> handlers anyway. You get a decent navigable data structure > >>> back > >>> >> from > >>> >> >> >> >> general SolrJ query requests as it is, there's no need to > >>> build in > >>> >> >> all > >>> >> >> >> these > >>> >> >> >> >> convenience methods specific to all the Solr componetry. > >>> Sure, > >>> >> it's > >>> >> >> >> >> "convenient", but it's a maintenance headache and as you > say, > >>> not > >>> >> >> >> generic. > >>> >> >> >> >> > >>> >> >> >> >> But hacking configuration is reasonable, I think, for > adding > >>> in > >>> >> >> plugins. > >>> >> >> >> I > >>> >> >> >> >> guess you're aiming for some kind of Spring-like > >>> auto-discovery of > >>> >> >> >> plugins? > >>> >> >> >> >> Yeah, maybe, but I'm pretty -1 on Spring coming into Solr. > >>> It's > >>> >> >> >> overkill > >>> >> >> >> >> and ugly, IMO. But you like it :) And that's cool by me, > to > >>> each > >>> >> >> their > >>> >> >> >> >> own. > >>> >> >> >> >> > >>> >> >> >> >> Oh, and Hi Mark! :) > >>> >> >> >> >> > >>> >> >> >> >> Erik > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > -- > >>> >> >> >> > Met vriendelijke groet, > >>> >> >> >> > > >>> >> >> >> > Martijn van Groningen > >>> >> >> >> > > >>> >> >> >> > >>> >> >> > > >>> >> >> > >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Met vriendelijke groet, > >>> >> > >>> >> Martijn van Groningen > >>> >> > >>> > > >>> > >>> > >>> > >>> -- > >>> Met vriendelijke groet, > >>> > >>> Martijn van Groningen > >>> > >> > >> > > >
