Hi Mozzam,
I finally got it working....
Thanks a ton guys :)
Regards
Raakhi
On Sat, Jul 10, 2010 at 10:45 AM, Moazzam Khan <moazz...@gmail.com> wrote:
> Hi Rakhi,
>
> Sorry, I didn't see this email until just now. Did you get it working?
>
>
> If not here's some things that might help.
>
>
> - Download the patch first.
> - Check the date on which the patch was released.
> - Download the version of the trunk that existed at that date.
> - Apply the patch using the patch program in linux. There is a Windows
> program for patching but I can't remember right now.
> - After applying the patch just compile the whole thing
>
>
> It might be better if you used the example folder first and modify the
> config to work for multicore (at least that's what I did) . You can
> compile example by doing
>
> ant example
>
> (if I remember correctly)
>
> For config stuff refer to this link :
>
> http://wiki.apache.org/solr/FieldCollapsing
>
>
> HTH :)
>
> - Moazzam
>
>
> I'd give you the
>
>
>
> On Wed, Jun 23, 2010 at 7:23 AM, Rakhi Khatwani <rkhatw...@gmail.com>
> wrote:
> > Hi,
> > But these is almost no settings in my config
> > heres a snapshot of what i have in my solrconfig.xml
> >
> > <config>
> > <updateHandler class="solr.DirectUpdateHandler2" />
> >
> > <requestDispatcher handleSelect="true" >
> > <requestParsers enableRemoteStreaming="false"
> > multipartUploadLimitInKB="2048" />
> > </requestDispatcher>
> >
> > <requestHandler name="standard" class="solr.StandardRequestHandler"
> > default="true" />
> > <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />
> > <requestHandler name="/admin/"
> > class="org.apache.solr.handler.admin.AdminHandlers" />
> >
> > <!-- config for the admin interface -->
> > <admin>
> > <defaultQuery>*:*</defaultQuery>
> > </admin>
> >
> > <!-- config for field collapsing -->
> > <searchComponent name="query"
> > class="org.apache.solr.handler.component.CollapseComponent" />
> > </config>
> >
> > Am i goin wrong anywhere?
> > Regards,
> > Raakhi
> >
> > On Wed, Jun 23, 2010 at 3:28 PM, Govind Kanshi <govind.kan...@gmail.com
> >wrote:
> >
> >> 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
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
>
