[dspace-tech] Re: Oai-PMH Data provider page doesn't resolved hostname correctly.

[Aprendiz 2018]

Hello, I have the same problem, is not updated: localhost:8080 in: 
http://repositorio.uct.edu.pe/oai/request?verb=ListSets, and modify the 
oai.cfg file and clean cache, but it continues anyway, please support me in 
the solution, thanks in advance. Greetings from Peru

El miércoles, 22 de junio de 2016, 15:10:49 (UTC-5), 
p.t...@garfield.uwinnipeg.ca escribió:
>
> hi all,
> I run into a problem with my "List of MetaData formats" page: Please see 
> the link:   
> http://winnspace.uwinnipeg.ca/oai/request?verb=ListMetadataFormat 
> s
>  If user click on any  " List records" buttons OR top right hand side 
> listing availables. The hostname resolved to (http://*127.0.0.1:8080 
> */oai/request?verb=ListRecords=qdc) 
> instead of the actual hostname (http://*winnspace.uwinnipeg.ca 
> *
> /oai/request?verb=ListRecords=qdc).
>
> how do I fix this issue?
>
> many thanks 
>
>
>
>
>   
>

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Need to delete records on OAI

[Aprendiz 2018]

Hello Andrea, I have a problem with the DSPACE and the OAI-PHM, similar to 
the one of Demmis, it is not possible to update the records in the OAI 
../oai/request?verb=ListSets, It shows me the old configuration and old 
records (33) Now they are 97. As I show you the output of the command:
# curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'




  0
  0
  
*:*
true
0
  






A help please,
Thanks

El lunes, 8 de febrero de 2016, 23:15:17 (UTC-5), Andrea Schweer escribió:
>
> Hi,
>
> I'm really not sure what's going on. Your log shows DSpace posting 
> information to Solr, which is what I'd expect. Have you checked the 
> permissions of the Solr directory tree? It needs to be owned by the same 
> user that Tomcat runs under ([dspace]/solr/oai and subdirectories).
>
> As a last resort, you could manually delete everything from that solr 
> index, then run another import. It shouldn't really do anything different 
> compared to clean-cache, but you never know. 
>
> If you run eg
> curl 'http://localhost:8080/solr/oai/select?q=*:*=true=0'
> then you'll see how many items the OAI solr core currently knows about -- 
> look for numFound. numFound should be equal to the number of items (this 
> might include non-public items and deleted items) after running import.
>
> You can run
> curl --globoff http://localhost:8080/solr/oai/update -H "Content-Type: 
> text/xml" --data-binary '*:*'
> followed by
> curl --globoff 'http://localhost:8080/solr/oai/update?commit=true'
> to force-delete everything in that solr index (you might want to try this 
> on a test server first).
>
> numFound in the first query above should then be 0. Run clean-cache and 
> access your web interface *without* running the import command -- it too 
> should tell you that there are 0 identifiers. If it still claims that there 
> are items, you may have a web cache layer in front of your repository or 
> something? If you do get 0 identifiers via the web interface after the 
> delete, run the import command and check again. Hopefully you'll then see 
> exactly those items you're expecting to see.
>
> Just a very final comment -- what are you looking at in the OAI interface? 
> I just followed the links in your initial e-mail again and the OAI 
> interface now shows 30 records/identifiers, the same number of items as 
> shown in JSPUI. So perhaps your earlier steps actually did work and you're 
> just looking at an out-of-date web page for some reason?
>
> cheers,
> Andrea
>
> On 09/02/16 16:48, Demis Estabridis wrote:
>
> Hi Andrea, 
>
> Thanks again for your answer.
> I can confirm that we're using SOLR as database source for OAI.
>
> We run again the suggested commands and we had no errors on the logs but 
> no new result. Nothing changed. 
>
> /opt/dspace/bin/dspace oai clean-cache
> /opt/dspace/bin/dspace oai import –c
>
> Please, find here the logs with debug mode on.
> We did it with the tomcat user:
>
> 2016-02-08 22:24:29,115 INFO  org.dspace.core.ConfigurationManager @ 
> Loading from classloader: file:/opt/dspace/config/dspace.cfg
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ Using 
> dspace provided log configuration (log.init.config)
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ 
> Loading: /opt/dspace/config/log4j.properties
> 2016-02-08 22:24:33,149 DEBUG net.sf.ehcache.config.ConfigurationFactory @ 
> Configuring ehcache from InputStream
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xmlns:xsi
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xsi:noNamespaceSchemaLocation
> 2016-02-08 22:24:33,280 DEBUG net.sf.ehcache.config.DiskStoreConfiguration 
> @ Disk Store Path: /tmp
> 2016-02-08 22:24:33,306 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheManagerEventListenerFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No BootstrapCacheLoaderFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheExceptionHandlerFactory class specified. Skipping...
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS is 'PostgreSQL'
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS driver version is '9.4.5'
> 2016-02-08 22:24:35,966 INFO  org.dspace.storage.rdbms.DatabaseUtils @ 
> Loading Flyway DB migrations from: filesystem:/opt/dspace/etc/postgres, 
> classpath:org.dspace.storage.rdbms.sqlmigration.postgres, 
> classpath:org.dspace.storage.rdbms.migration
> 2016-02-08 22:24:35,999 INFO 
>  org.flywaydb.core.internal.dbsupport.DbSupportFactory @ Database: 
> jdbc:postgresql://localhost:5432/dspace (PostgreSQL 9.4)
> 2016-02-08 22:24:36,005 DEBUG org.flywaydb.core.Flyway @ DDL Transactions 
> Supported: true
> 2016-02-08 22:24:36,018 DEBUG org.flywaydb.core.Flyway @ Schema: