lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Govind Kanshi <govind.kan...@gmail.com>
Subject Re: Field Collapsing SOLR-236
Date Wed, 23 Jun 2010 09:58:13 GMT
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 <rkhatwani@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 <rkhatwani@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 <rkhatwani@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.hier@gmail.com> wrote:
> >>
> >>> What exactly did not work? Patching, compiling or running it?
> >>>
> >>> On 22 June 2010 16:06, Rakhi Khatwani <rkhatwani@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.hier@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 <rkhatwani@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.hier@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 <rkhatwani@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 <
> >>> moazzamk@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.hier@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.hatcher@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
> >>>
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message