thank you Gert. That bit at least now works :-)

On 17 December 2013 10:10, Gert Schmeltz Pedersen <gerts...@gmail.com>wrote:

> Yes, the browseIndex page is not automatically modified during
> configuration, if you change the indexName from fgsIndex to something else.
> You have to change the SELECT element in your runtime
>
>
> webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/rest/adminBrowseIndexToHtml.xslt
>
> from
> <option value="fgsIndex">fgsIndex</option>
> to
> <option value="">default</option>
>
> The message "fgsIndex is not configured" is local to the browseIndex
> operation and due to the above option element. It is not due to the
> indexDir setting.
>
> The indexDir setting must be the path to the solr index.
>
> Thank you for pointing to unclear or incomplete configuration instructions.
>
> Gert
>
>
> On 16/12/2013, at 20.48, Peri Stracchino wrote:
>
> ok, thanks Gert
>
> Took your advice and tried reconfiguring from scratch, but I'm still
> struggling a bit here.
>
> The browseIndex reports that the fgsIndex is not configured.
>  In my fgsconfig-basic.properties I have my indexBase set to
> localhost:8080/solr, and my indexDir set
> to /opt/york/digilib/solr-3.6.1/data/index. The name of my gsearch index is
> YODL, as below
>
> namesOfIndexes=YODL
>  # FgsIndex: indexBase is the server base url, in case of Solr or Zebra.
>   #indexBase=http://localhost:8983/solr
>   indexBase=http://localhost:8080/solr
>
>   # FgsIndex: indexDir is the path to the index.
> indexDir=${local.FEDORA_HOME}/gsearch/FgsIndex
>   indexDir=/opt/york/digilib/solr-3.6.1/data/index
>
> should the indexDir configuration point to the solr/data/index, or to the
> fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/YODL?
>
>  I'v tried both, pointing to the solr index seems more correct but results
> in the "fgsIndex is not configured." message, however pointing to the index
> within gsearch seems wrong becauser then I get a message about missing
> segments, so it is surely expecting the solr index. So what is the further
> configuration of the fgsIndex that I need to do?
>
> tearing my hair out somewhat :-(
> Peri
>
>
>
>
>
> On 16 December 2013 10:42, Gert Schmeltz Pedersen <gerts...@gmail.com>wrote:
>
>> You should create a complete fgsconfigFinal/* using the procedure given
>> in GSearch 2.5 instead of reusing the old xslts.
>>
>> Also make sure that you include the field named PID as the unique key in
>> your runtime schema.xml for solr, see the three comments marked "For GSearch
>> 2.5" in schema-3.6.1-for-fgs-2.5.xml.
>>
>> Gert
>>
>>
>> On 16/12/2013, at 10.45, Peri Stracchino wrote:
>>
>> if i run updateFromPid i get Mon Dec 16 08:54:19 GMT 2013 Connection
>> error (is Solr running at http://yodlapp1.york.ac.uk/solr/update ?):
>> java.io.IOException: Server returned HTTP response code: 400 for URL:
>> http://yodlapp1.york.ac.uk/solr/update.
>> However solr is definately running on this url (its running on tomcat,
>> which is being proxied by apache webserver), I'm assuming this error is
>> being produced because its not actually getting documents to update in the
>> format it expects.  If I index a non foxml object using the solr post tool
>> , fedoragsearch will find this object when I use browseIndex using *:* as
>> the start term.
>>
>>
>> This is an example of one of the warnings:
>>
>> SEVERE: org.apache.solr.common.SolrException: ERROR: [doc=york:11269]
>> cannot set an index-time boost, norms are omitted for field PID: york:11269
>>         at
>> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:252)
>>         at
>> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
>>         at
>> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
>>         at
>> org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:157)
>>         at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
>>         at
>> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58)
>>         at
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>>         at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
>>         at
>> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365)
>>         at
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>         at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>>         at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>         at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>         at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>         at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>         at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
>>         at
>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>         at
>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
>>         at
>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
>>         at
>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
>>         at
>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
>>         at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>         at java.lang.Thread.run(Thread.java:679)
>>
>>
>>
>> at the end of my fedoragsearch.daily.log I have the following, which also
>> suggests to me that there is some further stylesheet editing needed all
>> these stylesheets were the ones I was using with solr 1.4, but I wonder if
>> I now need to make some changes to one or more of them  - the one we use
>> for our transformation  is solr-yodl-gsearch2v1.xslt, but is it possible
>> that I need to edit some other files to make it work with solr 3.6.1?
>>
>>   "DEBUG 2013-12-12 12:46:47,657 (Config) config created
>> configName=fgsconfigFinal errors=
>> DEBUG 2013-12-12 12:46:47,657 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/copyXml.xslt
>> DEBUG 2013-12-12 12:46:48,291 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGfindObjectsToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,564 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoUpdateIndexToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,598 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoBrowseIndexToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,641 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGetRepositoryInfoToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,659 (Config) checkStylesheet for
>> /fgsconfigFinal/rest/demoGetIndexInfoToHtml.xslt
>> DEBUG 2013-12-12 12:46:48,678 (Config) insertSystemProperties
>> propertyValue=/opt/york/digilib/fedora/data/objects
>> DEBUG 2013-12-12 12:46:48,678 (Config) checkStylesheet for
>> /fgsconfigFinal/repository/YODL/copyXml.xslt
>> DEBUG 2013-12-12 12:46:48,692 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/solr-yodl-gsearch2v1.xslt
>> DEBUG 2013-12-12 12:46:49,061 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/updateIndexToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,066 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/gfindObjectsToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,072 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/browseIndexToResultPage.xslt
>> DEBUG 2013-12-12 12:46:49,077 (Config) checkStylesheet for
>> /fgsconfigFinal/index/YODL/copyXml.xslt
>> DEBUG 2013-12-12 12:46:49,080 (Config) insertSystemProperties
>> propertyValue=/opt/york/digilib/solr-3.6.1/data/index
>> DEBUG 2013-12-12 12:46:49,080 (Config) checkAnalyzerClass
>> analyzerClassName=org.apache.lucene.analysis.standard.StandardAnalyzer
>> "
>>
>>
>> On 13 December 2013 21:19, Gert Schmeltz Pedersen <gerts...@gmail.com>wrote:
>>
>>> Hi Peri
>>>
>>> What do the warnings say?
>>>
>>> What happens if you updateIndex fromPid?
>>>
>>> Gert
>>>
>>>
>>> On 13/12/2013, at 19.42, Peri Stracchino wrote:
>>>
>>> > Hi
>>> > We've been running fedoragsearch 2.5 for quite a while against solr
>>> 1.4. We want to upgrade it to run against solr 3.6.1.
>>> > Now my solr 3.6.1 installation seems to be working ok - I can post and
>>> index the demonstration xml files. I can also see these files if I go to
>>> gsearch browseIndex and give *:* as my start term, so its obviously looking
>>> in the right place for the index.
>>> >
>>> >  But its not working properly against my new solr yet, because when I
>>> try to update index from foxml files, it runs then finishes with no
>>> documents indexed, just warnings
>>> >
>>> > I'v changed SOLR_HOME to the new solr
>>> > I have copied the schema.xml and solrconfig.xml from <SOLR_HOME>/conf
>>> into  fedoragsearch/WEB-INF/classes/fgsconfigFinal/<our index name>/conf.
>>>  the foxml to solr indexing format xslt transformation document we were
>>> using with the old solr version is still present.
>>> > fgsindex.indexBase    = http://<our server address>/solr
>>> > fgsindex.indexBase    =<oursolr_home>/data/index
>>> >
>>> > It must surely be looking in the right place for the foxml files,
>>> because 1) the fedora installation hasnt changed, and 2) its reporting an
>>> appropriate number of warnings, given the number of objects in the system
>>> and that each one has apparently failed. If I run uopdate index create
>>> empty it makes the usual request to manualy stop solr, clear the index and
>>> restart solr, when I run updateindex from foxml it initially starts without
>>> complaint - its only when it finishes that it emerges that nothing has
>>> actually indexed
>>> >
>>> > Is there some critical gsearch reconfiguration step I'v missed out, or
>>> can anyone suggest any useful way I can diagnose whats going wrong? I
>>> suspect perhaps there is something in the foxml files - or the output
>>> produced by the transformation script - which conflicts with the schema.xml
>>> - it this seems like the most likely scenario then I'll continue testing
>>> this line by line, but I'm concerned I may be looking in the wrong direction
>>> >
>>> > any pointers would be much appreciated!
>>> >
>>> > Peri
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Rapidly troubleshoot problems before they affect your business. Most IT
>>> > organizations don't have a clear picture of how application performance
>>> > affects their revenue. With AppDynamics, you get 100% visibility into
>>> your
>>> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>> AppDynamics Pro!
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>>> > Fedora-commons-users mailing list
>>> > Fedora-commons-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into
>>> your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>> AppDynamics Pro!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Fedora-commons-users mailing list
>>> Fedora-commons-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into
>> your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>> Fedora-commons-users mailing list
>> Fedora-commons-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Fedora-commons-users mailing list
>> Fedora-commons-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

Reply via email to