Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Thanks all. Found the issue at hand, and I think it might be a potential bug. So, I’m going to give you the scoop on what I found. It may be the solr is too restrictive—literally. 1. Created a collection that is a “dark copy”. It appears in the list of collections. 2. No index entries generated unless you are signed in. (Previous experience and versions did not do this). 3. Created a collection that is a public copy. It appears in the list of collection. 4. Index entries generated. I used the same file, and loaded into two different collections. So, is this a new undocumented feature or a bug in the solr implementation? Thanks, —Jeff Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... From: Andrea Bollini a.boll...@cineca.itmailto:a.boll...@cineca.it Date: Monday, January 20, 2014 at 5:20 PM To: Jeffrey Trimble jatrim...@ysu.edumailto:jatrim...@ysu.edu, dspace-tech@lists.sourceforge.netmailto:dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.netmailto:dspace-tech@lists.sourceforge.net Subject: R: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation The solr webapp is not working. Check the solr logs or try to access, from the server or using a ssh tunnel, the url http://rspace.cc.ysu.edu:8080/solr/http://rspace.cc.ysu.edu:8080/solr/search You should get more informations about the issue. Andrea Inviato da Samsung Mobile Messaggio originale Da: Jeffrey A Trimble Data:20/01/2014 22:30 (GMT+01:00) A: dspace-tech@lists.sourceforge.netmailto:dspace-tech@lists.sourceforge.net Oggetto: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation I just finished up a clean install of DSpace 4.0 on a server. I’m able to run the application, but if you choose any collection, the browser just sits there. But I’m seeing other errors too. So, here are the two problems I am seeing: Most important, these were all batch loaded as the first bitstreams into this server. Is that an undocumented feature? After editing one of them and updating it there now appears to be one index entries. But I “saw” before: 1. No index entries. I can retrieve by the URI or database # only. 2. Numerous solr errors in the logs: 2014-01-20 15:03:32,251 ERROR org.dspace.discovery.SolrServiceImpl @ Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:285) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:271) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:316) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:301) at org.dspace.discovery.SolrServiceImpl.indexContent(SolrServiceImpl.java:218) at org.dspace.discovery.IndexEventConsumer.end(IndexEventConsumer.java:170) at org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:147) at org.dspace.core.Context.commit(Context.java:373) at org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:987) at org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:780) at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:567) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) Any answers? Is batch loading somehow circumventing the solr indexing? TIA, JAT Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edumailto:jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Hi Jeff, This sounds like Discovery's normal actions (since DSpace 3.0). Discovery only shows content that you have access to. So, accessing the site as an anonymous user may show less content than if you access the site as a logged in user or Admin user. In other words, you only can see content that you actually have access to. Dark collections or Items will not appear to anonymous users. This is part of the Access rights based results feature that came in DSpace 3, briefly mentioned here: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-DSpace3.0 As of DSpace 4, of course, Discovery (Solr) is the default search browse system, which means that these Discovery features are now the default. It's possible some of these features do need to be made more prominent in the documentation, however. As they are now the default settings for DSpace 4 and above. - Tim On 1/21/2014 10:29 AM, Jeffrey A Trimble wrote: Thanks all. Found the issue at hand, and I think it might be a potential bug. So, I’m going to give you the scoop on what I found. It may be the solr is too restrictive—literally. 1.Created a collection that is a “dark copy”. It appears in the list of collections. 2.No index entries generated unless you are signed in. (Previous experience and versions did not do this). 3. Created a collection that is a public copy. It appears in the list of collection. 4.Index entries generated. I used the same file, and loaded into two different collections. So, is this a new undocumented feature or a bug in the solr implementation? Thanks, —Jeff Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... From: Andrea Bollini a.boll...@cineca.it mailto:a.boll...@cineca.it Date: Monday, January 20, 2014 at 5:20 PM To: Jeffrey Trimble jatrim...@ysu.edu mailto:jatrim...@ysu.edu, dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net Subject: R: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation The solr webapp is not working. Check the solr logs or try to access, from the server or using a ssh tunnel, the url http://rspace.cc.ysu.edu:8080/solr/ http://rspace.cc.ysu.edu:8080/solr/search You should get more informations about the issue. Andrea Inviato da Samsung Mobile Messaggio originale Da: Jeffrey A Trimble Data:20/01/2014 22:30 (GMT+01:00) A: dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net Oggetto: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation I just finished up a clean install of DSpace 4.0 on a server. I’m able to run the application, but if you choose any collection, the browser just sits there. But I’m seeing other errors too. So, here are the two problems I am seeing: Most important, these were all batch loaded as the first bitstreams into this server. Is that an undocumented feature? After editing one of them and updating it there now appears to be one index entries. But I “saw” before: 1. No index entries. I can retrieve by the URI or database # only. 2. Numerous solr errors in the logs: 2014-01-20 15:03:32,251 ERROR org.dspace.discovery.SolrServiceImpl @ Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:285) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:271) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:316) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:301) at org.dspace.discovery.SolrServiceImpl.indexContent(SolrServiceImpl.java:218) at org.dspace.discovery.IndexEventConsumer.end(IndexEventConsumer.java:170) at org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:147) at org.dspace.core.Context.commit(Context.java:373) at org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:987) at org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:780) at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:567
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Yes, now we have to have a fundamental discussion on ³dark copy². Does this mean that anything that is considered ³dark copy² is hidden from open discovery to patrons? In our case, no‹we want patrons to see what is available, and know that it needs special access. I find this is going to pose GRAVE issues for us to continue using the software since it is expected that dark copy means you cannot view it, but you can find it. What affect does this have on the harvesters? If this keeps the harvesters out of our system, I¹m really concerned since OCLC regularly harvests the data for OCLC (which we want). I cannot strongly‹I mean strongly recommend that this become something configurable ASAP. Until then, we will not be moving to 4.0 at any time soon. ‹Jeff Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... On 1/21/14, 11:38 AM, Tim Donohue tdono...@duraspace.org wrote: Hi Jeff, This sounds like Discovery's normal actions (since DSpace 3.0). Discovery only shows content that you have access to. So, accessing the site as an anonymous user may show less content than if you access the site as a logged in user or Admin user. In other words, you only can see content that you actually have access to. Dark collections or Items will not appear to anonymous users. This is part of the Access rights based results feature that came in DSpace 3, briefly mentioned here: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-DSpace3.0 As of DSpace 4, of course, Discovery (Solr) is the default search browse system, which means that these Discovery features are now the default. It's possible some of these features do need to be made more prominent in the documentation, however. As they are now the default settings for DSpace 4 and above. - Tim On 1/21/2014 10:29 AM, Jeffrey A Trimble wrote: Thanks all. Found the issue at hand, and I think it might be a potential bug. So, I¹m going to give you the scoop on what I found. It may be the solr is too restrictive‹literally. 1.Created a collection that is a ³dark copy². It appears in the list of collections. 2.No index entries generated unless you are signed in. (Previous experience and versions did not do this). 3. Created a collection that is a public copy. It appears in the list of collection. 4.Index entries generated. I used the same file, and loaded into two different collections. So, is this a new undocumented feature or a bug in the solr implementation? Thanks, ‹Jeff Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... From: Andrea Bollini a.boll...@cineca.it mailto:a.boll...@cineca.it Date: Monday, January 20, 2014 at 5:20 PM To: Jeffrey Trimble jatrim...@ysu.edu mailto:jatrim...@ysu.edu, dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net Subject: R: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation The solr webapp is not working. Check the solr logs or try to access, from the server or using a ssh tunnel, the url http://rspace.cc.ysu.edu:8080/solr/ http://rspace.cc.ysu.edu:8080/solr/search You should get more informations about the issue. Andrea Inviato da Samsung Mobile Messaggio originale Da: Jeffrey A Trimble Data:20/01/2014 22:30 (GMT+01:00) A: dspace-tech@lists.sourceforge.net mailto:dspace-tech@lists.sourceforge.net Oggetto: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation I just finished up a clean install of DSpace 4.0 on a server. I¹m able to run the application, but if you choose any collection, the browser just sits there. But I¹m seeing other errors too. So, here are the two problems I am seeing: Most important, these were all batch loaded as the first bitstreams into this server. Is that an undocumented feature? After editing one of them and updating it there now appears to be one index entries. But I ³saw² before: 1. No index entries. I can retrieve by the URI or database # only. 2. Numerous solr errors in the logs: 2014-01-20 15:03:32,251 ERROR org.dspace.discovery.SolrServiceImpl @ Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.j ava:385
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
We should better document how to turn off/on Access Rights Awareness. I *believe* it's a matter of commenting out this setting (but it's unclear to me as well, and I don't know enough about this feature): https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/discovery.xml#L25 To clarify here, different institutions definitely have different use cases for DSpace, and often based on the use case they may have differing opinions of this feature. There are institutions who are adamantly in favor of Access Rights Awareness (as they do NOT want Google/Google Scholar to index items whose metadata is private -- e.g. some of those items may be private records or embargoed and they do not wish them to be discoverable at all). There are also insitutions (which Jeff helix84 are members) who are adamantly against Access Rights Awareness (as they want Google to index all metadata, whether that item is private or public or embargoed). So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. - Tim On 1/21/2014 11:12 AM, helix84 wrote: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Il 21/01/2014 18.12, helix84 ha scritto: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Sorry, I disagree. The items are hidden because metadata has been marked as not accessible to anonymous user. If you want metadata to be visible you can just grant READ permission for the item to the anonymous group and keep reserved the bitstream. If you really have a requirement to have some limited metadata available (say, title, authors and all the other browse column) and keep the other reserved you can turn off the access rights awareness features but IMHO this is a very uncommon need (and also check careful what happen on the oai-pmh / rest endpoint) Andrea Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Andrea Bollini Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria Divisione Ricerca Via dei Tizii, 6 00185 Roma, Italy tel. +39 06 44 486 087 - mob. +39 348 82 77 525 http://www.cineca.it -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Il 21/01/2014 18.38, Tim Donohue ha scritto: We should better document how to turn off/on Access Rights Awareness. I *believe* it's a matter of commenting out this setting (but it's unclear to me as well, and I don't know enough about this feature): https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/discovery.xml#L25 Yes it is just a matter to comment out or remove the bean definition. The solr indexing process discover automatically https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/discovery/SolrServiceImpl.java#L724 all the registered beans that implement the interface org.dspace.discovery.SolrServiceIndexPlugin and call them to add extra information to the solr index. Andrea To clarify here, different institutions definitely have different use cases for DSpace, and often based on the use case they may have differing opinions of this feature. There are institutions who are adamantly in favor of Access Rights Awareness (as they do NOT want Google/Google Scholar to index items whose metadata is private -- e.g. some of those items may be private records or embargoed and they do not wish them to be discoverable at all). There are also insitutions (which Jeff helix84 are members) who are adamantly against Access Rights Awareness (as they want Google to index all metadata, whether that item is private or public or embargoed). So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. - Tim On 1/21/2014 11:12 AM, helix84 wrote: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Andrea Bollini Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria Divisione Ricerca Via dei Tizii, 6 00185 Roma, Italy tel. +39 06 44 486 087 - mob. +39 348 82 77 525 http://www.cineca.it -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
It seems we have a healthy discussion about Œdark copy¹ and this is good. So the culprit was not the software itself, but the documentation as to how this could be configured. I guess, I might be back in the Editor Gardner¹s seat very soon. Thanks to Tim, Helix, and Andrea for their valuable insights in assisting me and my endeavors. ‹Jeff Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... On 1/21/14, 12:48 PM, Tim Donohue tdono...@duraspace.org wrote: As a followup to my own email: It looks like it *is* documented how to disable this Access Rights Awareness feature. It's just not so easy to find the docs on it. Here's the details: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-Accessitemb asedresults So, we probably just need to make this a little easier to find. It took some searching in the docs before I realized it actually is there. I agree with Andrea Bollini here though. I personally like this feature. I can understand there may be use cases where it's not desirable. But, by default, I'd prefer we *hide* metadata for access-restricted Items, rather than making it publicly available/searchable. - Tim On 1/21/2014 11:38 AM, Tim Donohue wrote: We should better document how to turn off/on Access Rights Awareness. I *believe* it's a matter of commenting out this setting (but it's unclear to me as well, and I don't know enough about this feature): https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/dis covery.xml#L25 To clarify here, different institutions definitely have different use cases for DSpace, and often based on the use case they may have differing opinions of this feature. There are institutions who are adamantly in favor of Access Rights Awareness (as they do NOT want Google/Google Scholar to index items whose metadata is private -- e.g. some of those items may be private records or embargoed and they do not wish them to be discoverable at all). There are also insitutions (which Jeff helix84 are members) who are adamantly against Access Rights Awareness (as they want Google to index all metadata, whether that item is private or public or embargoed). So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. - Tim On 1/21/2014 11:12 AM, helix84 wrote: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=co m.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2 5563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
On Tue, Jan 21, 2014 at 11:38:58AM -0600, Tim Donohue wrote: [snip] So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. I will certainly never argue against documenting the behavior of code. But from another posting, it sounds to me that the problem is one of granting the proper rights to express your institution's policy: grant READ on the Item to users and groups who should be able to see the metadata, and READ on a Bitstream to users and groups who should be able to see the bitstream data. We may need to improve the administrative UI to make crafting access-control lists more convenient. At the least we need to provide that the default ACL on each object type is adjustable, so that the policy a site usually wants can be the default at that site. (This may need to be a property of the Community or Collection.) The default default ACL should then express the most restrictive reasonable policy, which might very well be no access by anyone. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
Based on this email thread, I went ahead and made some enhancements to the Discovery documentation (including renaming the feature as Access Rights Awareness). The enhanced documentation on how this feature works and how you can disable it are at: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-AccessRightsAwareness Feel free to enhance it even more. But, I've tried to at least capture the main hints provided by folks in this thread. - Tim On 1/21/2014 11:48 AM, Tim Donohue wrote: As a followup to my own email: It looks like it *is* documented how to disable this Access Rights Awareness feature. It's just not so easy to find the docs on it. Here's the details: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-Accessitembasedresults So, we probably just need to make this a little easier to find. It took some searching in the docs before I realized it actually is there. I agree with Andrea Bollini here though. I personally like this feature. I can understand there may be use cases where it's not desirable. But, by default, I'd prefer we *hide* metadata for access-restricted Items, rather than making it publicly available/searchable. - Tim On 1/21/2014 11:38 AM, Tim Donohue wrote: We should better document how to turn off/on Access Rights Awareness. I *believe* it's a matter of commenting out this setting (but it's unclear to me as well, and I don't know enough about this feature): https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/discovery.xml#L25 To clarify here, different institutions definitely have different use cases for DSpace, and often based on the use case they may have differing opinions of this feature. There are institutions who are adamantly in favor of Access Rights Awareness (as they do NOT want Google/Google Scholar to index items whose metadata is private -- e.g. some of those items may be private records or embargoed and they do not wish them to be discoverable at all). There are also insitutions (which Jeff helix84 are members) who are adamantly against Access Rights Awareness (as they want Google to index all metadata, whether that item is private or public or embargoed). So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. - Tim On 1/21/2014 11:12 AM, helix84 wrote: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
As a followup to my own email: It looks like it *is* documented how to disable this Access Rights Awareness feature. It's just not so easy to find the docs on it. Here's the details: https://wiki.duraspace.org/display/DSDOC4x/Discovery#Discovery-Accessitembasedresults So, we probably just need to make this a little easier to find. It took some searching in the docs before I realized it actually is there. I agree with Andrea Bollini here though. I personally like this feature. I can understand there may be use cases where it's not desirable. But, by default, I'd prefer we *hide* metadata for access-restricted Items, rather than making it publicly available/searchable. - Tim On 1/21/2014 11:38 AM, Tim Donohue wrote: We should better document how to turn off/on Access Rights Awareness. I *believe* it's a matter of commenting out this setting (but it's unclear to me as well, and I don't know enough about this feature): https://github.com/DSpace/DSpace/blob/master/dspace/config/spring/api/discovery.xml#L25 To clarify here, different institutions definitely have different use cases for DSpace, and often based on the use case they may have differing opinions of this feature. There are institutions who are adamantly in favor of Access Rights Awareness (as they do NOT want Google/Google Scholar to index items whose metadata is private -- e.g. some of those items may be private records or embargoed and they do not wish them to be discoverable at all). There are also insitutions (which Jeff helix84 are members) who are adamantly against Access Rights Awareness (as they want Google to index all metadata, whether that item is private or public or embargoed). So, Access Rights Awareness is probably something we need to better document also better document how to disable it if you favor exposing *all* metadata as publicly searchable/browsable. - Tim On 1/21/2014 11:12 AM, helix84 wrote: Hi Jeff, here's how you can turn Access Rights Awareness off: https://jira.duraspace.org/browse/DS-1229?focusedCommentId=25563page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25563 I also find it unfortunate that it's on by default. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] R: Tomcat 7.0.50 and Dspace 4.0 Implementation
The solr webapp is not working. Check the solr logs or try to access, from the server or using a ssh tunnel, the url http://rspace.cc.ysu.edu:8080/solr/ You should get more informations about the issue. Andrea Inviato da Samsung Mobile Messaggio originale Da: Jeffrey A Trimble jatrim...@ysu.edu Data:20/01/2014 22:30 (GMT+01:00) A: dspace-tech@lists.sourceforge.net Oggetto: [Dspace-tech] Tomcat 7.0.50 and Dspace 4.0 Implementation I just finished up a clean install of DSpace 4.0 on a server. I’m able to run the application, but if you choose any collection, the browser just sits there. But I’m seeing other errors too. So, here are the two problems I am seeing: Most important, these were all batch loaded as the first bitstreams into this server. Is that an undocumented feature? After editing one of them and updating it there now appears to be one index entries. But I “saw” before: 1. No index entries. I can retrieve by the URI or database # only. 2. Numerous solr errors in the logs: 2014-01-20 15:03:32,251 ERROR org.dspace.discovery.SolrServiceImpl @ Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://rspace.cc.ysu.edu:8080/solr/search returned non ok status:500, message:Internal Server Error at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:285) at org.apache.solr.client.solrj.SolrServer.deleteByQuery(SolrServer.java:271) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:316) at org.dspace.discovery.SolrServiceImpl.unIndexContent(SolrServiceImpl.java:301) at org.dspace.discovery.SolrServiceImpl.indexContent(SolrServiceImpl.java:218) at org.dspace.discovery.IndexEventConsumer.end(IndexEventConsumer.java:170) at org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:147) at org.dspace.core.Context.commit(Context.java:373) at org.dspace.app.itemimport.ItemImport.addItem(ItemImport.java:987) at org.dspace.app.itemimport.ItemImport.addItems(ItemImport.java:780) at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:567) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) Any answers? Is batch loading somehow circumventing the solr indexing? TIA, JAT Jeffrey Trimble Associate Director Head of Information Services William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu For he is the Kwisatz Haderach... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
