Hi Nick, OAI *does* index license files for specific metadata formats. While this may seem odd, it's worth remembering that OAI-PMH is a generic protocol that supports a configurable number of metadata output formats. Base formats like "oai_dc" and "qdc" obviously don't use the license information... but other formats like "mets" and "ore" *do* use and provide license information.
Here's the code where the license info is indexed in OAI: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-oai/src/main/java/org/dspace/xoai/util/ItemUtils.java#L283 Here's an example (from the demo site) of two formats that use/provide the license info for harvesting: * METS format: http://demo.dspace.org/oai/request?verb=GetRecord&metadataPrefix=mets&identifier=oai:demo.dspace.org:10673/4 * ORE format: http://demo.dspace.org/oai/request?verb=GetRecord&metadataPrefix=ore&identifier=oai:demo.dspace.org:10673/4 Of course, OAI is configurable, so you can turn off various output metadata formats using the configurations under [dspace]/config/crosswalks/oai/ However, unfortunately, this doesn't look to affect the indexing of the license file. DSpace is indexing that license file for OAI *just in case* an output format wants to use it -- it isn't doing any pre-determination of whether that license file is actually going to be used. I hope that helps explains the initial question. As to whether License bundles should have authorization policies -- yes, all bundles always should have authorization policies. However, there is no requirement that License bundles *must be publicly accessible*. So, if this is what you seem to be seeing, I'd recommend logging a bug ticket, as I think OAI should be smart enough to skip indexing any licenses that are access restricted. - Tim On Wed, Oct 10, 2018 at 10:09 AM Nicholas Woodward < [email protected]> wrote: > On our DSpace 6.3 instance we're seeing an authorization error on the > license.txt bitstreams when we run `oai import`. The license bundles and > bitstreams don't have any authorization policies attached to them. I know > I've seen a few Jira issues related to this issue with code that has been > merged, so I'm a bit confused why it's still happening with our instance. > > > My questions are: should the oai process be harvesting license.txt files > in the first place? Is there some configuration I could add to the XOAI > config that would ignore these bundles? Or do the license.txt bundles > *need* to have authorization policies attached to them? > > > Thanks, > Nick > > > > WARN org.dspace.xoai.util.ItemUtils @ Authorization denied for action > READ on BITSTREAM:[uuid] by user null > org.dspace.authorize.AuthorizeException: Authorization denied for action > READ on BITSTREAM:[uuid] by user null > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:157) > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:95) > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:89) > at > org.dspace.content.BitstreamServiceImpl.retrieve(BitstreamServiceImpl.java:307) > at > org.dspace.xoai.util.ItemUtils.retrieveMetadata(ItemUtils.java:298) > at org.dspace.xoai.app.XOAI.index(XOAI.java:424) > at org.dspace.xoai.app.XOAI.index(XOAI.java:282) > at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:227) > at org.dspace.xoai.app.XOAI.index(XOAI.java:134) > at org.dspace.xoai.app.XOAI.main(XOAI.java:563) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229) > at > org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81) > ERROR org.dspace.xoai.app.XOAI @ > java.lang.NullPointerException > at org.dspace.xoai.app.XOAI.willChangeStatus(XOAI.java:441) > at org.dspace.xoai.app.XOAI.index(XOAI.java:371) > at org.dspace.xoai.app.XOAI.index(XOAI.java:282) > at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:227) > at org.dspace.xoai.app.XOAI.index(XOAI.java:134) > at org.dspace.xoai.app.XOAI.main(XOAI.java:563) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229) > at > org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81) > > > > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
