Re: [dspace-tech] Re: CC License step failing

[George Kozak]

Hi, Everyone:
I made the suggested change from http to https, but I still have failure in
connecting to Creative Commons.  I restarted tomcat and cleared the cocoon
cache, as well.
George Kozak
Cornell University

On Mon, Apr 2, 2018 at 7:59 PM, Javier Távara  wrote:

> Thank you for the update Rob.
>
> Any redirection is being applied from non-SSL to SSL? Was the same before
> the update?
>
> I changed my settings (dspace.cfg) to use SSL:
>
> # The url to the web service API
> cc.api.rooturl = https://api.creativecommons.org/rest/1.5
>
> And it works now :)
>
> - Javier.
>
> El lunes, 2 de abril de 2018, 18:51:16 (UTC-5), Rob Myers escribió:
>>
>> Heya everyone, Rob from Creative Commons here.
>>
>> I'm very sorry that our API isn't working with DSpace at the moment. I
>> upgraded the server that the API runs on, and the problem that you are
>> seeing wasn't caught by my tests.
>>
>> If I call the API simply via the command line, e.g.:
>>
>> curl -d "answers=en> ercial>ysa> ion>UntitledA.
>> N. 
>> Otherhttps://example.com/untitled"
>> https://api.creativecommons.org/rest/1.5/license/standard/issue
>>
>> Then I do get back an xml block, e.g.:
>>
>> 
>> 
>>   http://creativecommons.org/licenses/by-sa/4.0/<
>> /license-uri>
>>   Attribution-ShareAlike 4.0 International
>>   false
>>   
>> http://creativecommons.org/ns#; xmlns:rdf="
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>   http://purl.org/dc/elements/1.1/; rdf:about="
>> https://example.com/untitled;>UntitledA.
>> N. Otherhttp://creativec
>> ommons.org/licenses/by-sa/4.0/"/>http://creativecommons.org/licenses/by-sa/4.0/;>
>> http://creativecommons.org/ns#DerivativeWorks;
>> />
>> http://creativecommons.org/ns#Distribution"/>
>> http://creativecommons.org/ns#Reproduction"/>
>> http://creativecommons.org/ns#Attribution"/>
>> http://creativecommons.org/ns#Notice"/>
>> http://creativecommons.org/ns#ShareAlike"/>
>>   
>> 
>>   
>>   
>> http://creativecommons.org/ns#; xmlns:rdf="
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>   http://creativecommons.org/licenses/by-sa/4.0/;>
>> http://creativecommons.org/ns#DerivativeWorks;
>> />
>> http://creativecommons.org/ns#Distribution"/>
>> http://creativecommons.org/ns#Reproduction"/>
>> http://creativecommons.org/ns#Attribution"/>
>> http://creativecommons.org/ns#Notice"/>
>> http://creativecommons.org/ns#ShareAlike"/>
>>   
>> 
>>   
>>   http://creativecommons.o
>> rg/licenses/by-sa/4.0/">> style="border-width:0" src="http://i.creativecommons.
>> org/l/by-sa/4.0/88x31.png"/>http://purl.org/dc/
>> terms/" property="dct:title">Untitled by http://creativecommons.org/ns#; href="https://example.com/untitled;
>> property="cc:attributionName" rel="cc:attributionURL">A. N. Other is
>> licensed under a http://creativecommons.o
>> rg/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0
>> International License.
>> 
>>
>> Which does validate OK locally.
>>
>> The only thing that should have changed for users of the API is the SSL
>> certificate for the domain (might the old one be being cached somewhere?),
>> although the versions of Python and Apache Web server that the software
>> runs of have jumped a few versions, so it is possible that something else
>> has changed without me catching it.
>>
>> I'd be very grateful if anyone could pass me any further information,
>> particularly if anyone can see what api.creativecommons.org thinks it is
>> sending back to DSpace in response to a license request.
>>
>> Thank you, and again my apologies for this.
>>
>> - Rob Myers,
>> Core Systems Manager,
>> Creative Commons.
>>
>>
>> On Monday, April 2, 2018 at 3:38:07 PM UTC-7, Javier Távara wrote:
>>>
>>> I saw the tweets. Thank you.
>>>
>>> As we don't have any useful logs of what's happening, I thought
>>> disabling/enabling the step could fire any sort of cache clearing.
>>>
>>> No success.
>>>
>>> - Javier
>>>
>>> El lunes, 2 de abril de 2018, 17:33:16 (UTC-5), Keith Gilbertson
>>> escribió:



 On Monday, April 2, 2018 at 6:18:47 PM UTC-4, Javier Távara wrote:
>
> I really don't want to disable the CC License step.
>
> That's understandable. Our repository team has been encouraging people
 to select CC licenses.
 Rob Myers at Creative Commons is aware that some DSpace repositories
 have had an issue, but it's now past normal working hours, and I haven't
 been able to provide him with any useful information as to what's
 specifically causing the problem.


 Disabling/enabling fixes nothing by the way.
>
> I had to comment out the CC License step in multiple locations in the
 item-submission.xml file on our test server, and then restart Tomcat. I
 think you are offering additional information that the CC License step
 still doesn't work once you enable it again.



> - Javier.
>
> El lunes, 2 de abril de 2018, 16:43:29 

[dspace-tech] Re: CC License step failing

[Rob Myers]

Heya Javier.

Thank you for checking this.

There is a 301 redirect in place from http to https.

The old server had Varnish publicly accessible on port 80, which I assumed 
was an error so I didn't recreate that (we were meant to have switched 
everything to https a couple of years ago!).

If changing to https fixes the issue, this would explain it.

Is it easy to change cc.api.rooturl to https, or is that going to be a pain 
for people?

Thank you again.

- Rob.

On Monday, April 2, 2018 at 4:59:23 PM UTC-7, Javier Távara wrote:
>
> Thank you for the update Rob.
>
> Any redirection is being applied from non-SSL to SSL? Was the same before 
> the update?
>
> I changed my settings (dspace.cfg) to use SSL:
>
> # The url to the web service API
> cc.api.rooturl = https://api.creativecommons.org/rest/1.5
>
> And it works now :)
>
> - Javier.
>
> El lunes, 2 de abril de 2018, 18:51:16 (UTC-5), Rob Myers escribió:
>>
>> Heya everyone, Rob from Creative Commons here.
>>
>> I'm very sorry that our API isn't working with DSpace at the moment. I 
>> upgraded the server that the API runs on, and the problem that you are 
>> seeing wasn't caught by my tests.
>>
>> If I call the API simply via the command line, e.g.:
>>
>> curl -d 
>> "answers=enysaUntitledA.
>>  
>> N. 
>> Otherhttps://example.com/untitled"
>>  
>> https://api.creativecommons.org/rest/1.5/license/standard/issue
>>
>> Then I do get back an xml block, e.g.:
>>
>> 
>> 
>>   http://creativecommons.org/licenses/by-sa/4.0/
>> 
>>   Attribution-ShareAlike 4.0 International
>>   false
>>   
>> http://creativecommons.org/ns#; xmlns:rdf="
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>   http://purl.org/dc/elements/1.1/; rdf:about="
>> https://example.com/untitled;>UntitledA. 
>> N. Otherhttp://creativecommons.org/licenses/by-sa/4.0/"/>> rdf:about="http://creativecommons.org/licenses/by-sa/4.0/;>
>> http://creativecommons.org/ns#DerivativeWorks
>> "/>
>> http://creativecommons.org/ns#Distribution"/>
>> http://creativecommons.org/ns#Reproduction"/>
>> http://creativecommons.org/ns#Attribution"/>
>> http://creativecommons.org/ns#Notice"/>
>> http://creativecommons.org/ns#ShareAlike"/>
>>   
>> 
>>   
>>   
>> http://creativecommons.org/ns#; xmlns:rdf="
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>   http://creativecommons.org/licenses/by-sa/4.0/;>
>> http://creativecommons.org/ns#DerivativeWorks
>> "/>
>> http://creativecommons.org/ns#Distribution"/>
>> http://creativecommons.org/ns#Reproduction"/>
>> http://creativecommons.org/ns#Attribution"/>
>> http://creativecommons.org/ns#Notice"/>
>> http://creativecommons.org/ns#ShareAlike"/>
>>   
>> 
>>   
>>   http://creativecommons.org/licenses/by-sa/4.0/;>http://i.creativecommons.org/l/by-sa/4.0/88x31.png"/>> xmlns:dct="http://purl.org/dc/terms/; 
>> property="dct:title">Untitled by http://creativecommons.org/ns#; href="https://example.com/untitled; 
>> property="cc:attributionName" rel="cc:attributionURL">A. N. Other is 
>> licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
>> Attribution-ShareAlike 4.0 International License.
>> 
>>
>> Which does validate OK locally.
>>
>> The only thing that should have changed for users of the API is the SSL 
>> certificate for the domain (might the old one be being cached somewhere?), 
>> although the versions of Python and Apache Web server that the software 
>> runs of have jumped a few versions, so it is possible that something else 
>> has changed without me catching it.
>>
>> I'd be very grateful if anyone could pass me any further information, 
>> particularly if anyone can see what api.creativecommons.org thinks it is 
>> sending back to DSpace in response to a license request.
>>
>> Thank you, and again my apologies for this.
>>
>> - Rob Myers,
>> Core Systems Manager,
>> Creative Commons.
>>
>>
>> On Monday, April 2, 2018 at 3:38:07 PM UTC-7, Javier Távara wrote:
>>>
>>> I saw the tweets. Thank you.
>>>
>>> As we don't have any useful logs of what's happening, I thought 
>>> disabling/enabling the step could fire any sort of cache clearing.
>>>
>>> No success.
>>>
>>> - Javier
>>>
>>> El lunes, 2 de abril de 2018, 17:33:16 (UTC-5), Keith Gilbertson 
>>> escribió:



 On Monday, April 2, 2018 at 6:18:47 PM UTC-4, Javier Távara wrote:
>
> I really don't want to disable the CC License step.
>
> That's understandable. Our repository team has been encouraging people 
 to select CC licenses. 
 Rob Myers at Creative Commons is aware that some DSpace repositories 
 have had an issue, but it's now past normal working hours, and I haven't 
 been able to provide him with any useful information as to what's 
 specifically causing the problem.


 Disabling/enabling fixes nothing by the way.
>
> I had to comment out the CC License step in multiple locations in the 
 item-submission.xml file on our test server, 

[dspace-tech] Re: CC License step failing

[Javier Távara]

Thank you for the update Rob.

Any redirection is being applied from non-SSL to SSL? Was the same before 
the update?

I changed my settings (dspace.cfg) to use SSL:

# The url to the web service API
cc.api.rooturl = https://api.creativecommons.org/rest/1.5

And it works now :)

- Javier.

El lunes, 2 de abril de 2018, 18:51:16 (UTC-5), Rob Myers escribió:
>
> Heya everyone, Rob from Creative Commons here.
>
> I'm very sorry that our API isn't working with DSpace at the moment. I 
> upgraded the server that the API runs on, and the problem that you are 
> seeing wasn't caught by my tests.
>
> If I call the API simply via the command line, e.g.:
>
> curl -d 
> "answers=enysaUntitledA.
>  
> N. 
> Otherhttps://example.com/untitled"
>  
> https://api.creativecommons.org/rest/1.5/license/standard/issue
>
> Then I do get back an xml block, e.g.:
>
> 
> 
>   http://creativecommons.org/licenses/by-sa/4.0/
> 
>   Attribution-ShareAlike 4.0 International
>   false
>   
> http://creativecommons.org/ns#; xmlns:rdf="
> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>   http://purl.org/dc/elements/1.1/; rdf:about="
> https://example.com/untitled;>UntitledA. 
> N. Otherhttp://creativecommons.org/licenses/by-sa/4.0/"/> rdf:about="http://creativecommons.org/licenses/by-sa/4.0/;>
> http://creativecommons.org/ns#DerivativeWorks
> "/>
> http://creativecommons.org/ns#Distribution"/>
> http://creativecommons.org/ns#Reproduction"/>
> http://creativecommons.org/ns#Attribution"/>
> http://creativecommons.org/ns#Notice"/>
> http://creativecommons.org/ns#ShareAlike"/>
>   
> 
>   
>   
> http://creativecommons.org/ns#; xmlns:rdf="
> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>   http://creativecommons.org/licenses/by-sa/4.0/;>
> http://creativecommons.org/ns#DerivativeWorks
> "/>
> http://creativecommons.org/ns#Distribution"/>
> http://creativecommons.org/ns#Reproduction"/>
> http://creativecommons.org/ns#Attribution"/>
> http://creativecommons.org/ns#Notice"/>
> http://creativecommons.org/ns#ShareAlike"/>
>   
> 
>   
>   http://creativecommons.org/licenses/by-sa/4.0/;>http://i.creativecommons.org/l/by-sa/4.0/88x31.png"/> xmlns:dct="http://purl.org/dc/terms/; 
> property="dct:title">Untitled by http://creativecommons.org/ns#; href="https://example.com/untitled; 
> property="cc:attributionName" rel="cc:attributionURL">A. N. Other is 
> licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
> Attribution-ShareAlike 4.0 International License.
> 
>
> Which does validate OK locally.
>
> The only thing that should have changed for users of the API is the SSL 
> certificate for the domain (might the old one be being cached somewhere?), 
> although the versions of Python and Apache Web server that the software 
> runs of have jumped a few versions, so it is possible that something else 
> has changed without me catching it.
>
> I'd be very grateful if anyone could pass me any further information, 
> particularly if anyone can see what api.creativecommons.org thinks it is 
> sending back to DSpace in response to a license request.
>
> Thank you, and again my apologies for this.
>
> - Rob Myers,
> Core Systems Manager,
> Creative Commons.
>
>
> On Monday, April 2, 2018 at 3:38:07 PM UTC-7, Javier Távara wrote:
>>
>> I saw the tweets. Thank you.
>>
>> As we don't have any useful logs of what's happening, I thought 
>> disabling/enabling the step could fire any sort of cache clearing.
>>
>> No success.
>>
>> - Javier
>>
>> El lunes, 2 de abril de 2018, 17:33:16 (UTC-5), Keith Gilbertson escribió:
>>>
>>>
>>>
>>> On Monday, April 2, 2018 at 6:18:47 PM UTC-4, Javier Távara wrote:

 I really don't want to disable the CC License step.

 That's understandable. Our repository team has been encouraging people 
>>> to select CC licenses. 
>>> Rob Myers at Creative Commons is aware that some DSpace repositories 
>>> have had an issue, but it's now past normal working hours, and I haven't 
>>> been able to provide him with any useful information as to what's 
>>> specifically causing the problem.
>>>
>>>
>>> Disabling/enabling fixes nothing by the way.

 I had to comment out the CC License step in multiple locations in the 
>>> item-submission.xml file on our test server, and then restart Tomcat. I 
>>> think you are offering additional information that the CC License step 
>>> still doesn't work once you enable it again.
>>>
>>>  
>>>
 - Javier.

 El lunes, 2 de abril de 2018, 16:43:29 (UTC-5), Keith Gilbertson 
 escribió:
>
> George, we've had similar problems today. We'll probably disable CC 
> License steps for now, and then restart Tomcat. On our system, this is 
> configured in /dspace/conf/item-submission.xml
> --keith
>
> On Monday, April 2, 2018 at 5:31:29 PM UTC-4, George Kozak wrote:
>>
>> Hi,
>> We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the 
>> CC 

[dspace-tech] Re: CC License step failing

[Rob Myers]

Heya everyone, Rob from Creative Commons here.

I'm very sorry that our API isn't working with DSpace at the moment. I 
upgraded the server that the API runs on, and the problem that you are 
seeing wasn't caught by my tests.

If I call the API simply via the command line, e.g.:

curl -d 
"answers=enysaUntitledA.
 
N. 
Otherhttps://example.com/untitled"
 
https://api.creativecommons.org/rest/1.5/license/standard/issue

Then I do get back an xml block, e.g.:



  http://creativecommons.org/licenses/by-sa/4.0/
  Attribution-ShareAlike 4.0 International
  false
  
http://creativecommons.org/ns#; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
  http://purl.org/dc/elements/1.1/; 
rdf:about="https://example.com/untitled;>UntitledA.
 
N. Otherhttp://creativecommons.org/licenses/by-sa/4.0/"/>http://creativecommons.org/licenses/by-sa/4.0/;>
http://creativecommons.org/ns#DerivativeWorks"/>
http://creativecommons.org/ns#Distribution"/>
http://creativecommons.org/ns#Reproduction"/>
http://creativecommons.org/ns#Attribution"/>
http://creativecommons.org/ns#Notice"/>
http://creativecommons.org/ns#ShareAlike"/>
  

  
  
http://creativecommons.org/ns#; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
  http://creativecommons.org/licenses/by-sa/4.0/;>
http://creativecommons.org/ns#DerivativeWorks"/>
http://creativecommons.org/ns#Distribution"/>
http://creativecommons.org/ns#Reproduction"/>
http://creativecommons.org/ns#Attribution"/>
http://creativecommons.org/ns#Notice"/>
http://creativecommons.org/ns#ShareAlike"/>
  

  
  http://creativecommons.org/licenses/by-sa/4.0/;>http://i.creativecommons.org/l/by-sa/4.0/88x31.png"/>http://purl.org/dc/terms/; property="dct:title">Untitled 
by http://creativecommons.org/ns#; 
href="https://example.com/untitled; property="cc:attributionName" 
rel="cc:attributionURL">A. N. Other is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.


Which does validate OK locally.

The only thing that should have changed for users of the API is the SSL 
certificate for the domain (might the old one be being cached somewhere?), 
although the versions of Python and Apache Web server that the software 
runs of have jumped a few versions, so it is possible that something else 
has changed without me catching it.

I'd be very grateful if anyone could pass me any further information, 
particularly if anyone can see what api.creativecommons.org thinks it is 
sending back to DSpace in response to a license request.

Thank you, and again my apologies for this.

- Rob Myers,
Core Systems Manager,
Creative Commons.


On Monday, April 2, 2018 at 3:38:07 PM UTC-7, Javier Távara wrote:
>
> I saw the tweets. Thank you.
>
> As we don't have any useful logs of what's happening, I thought 
> disabling/enabling the step could fire any sort of cache clearing.
>
> No success.
>
> - Javier
>
> El lunes, 2 de abril de 2018, 17:33:16 (UTC-5), Keith Gilbertson escribió:
>>
>>
>>
>> On Monday, April 2, 2018 at 6:18:47 PM UTC-4, Javier Távara wrote:
>>>
>>> I really don't want to disable the CC License step.
>>>
>>> That's understandable. Our repository team has been encouraging people 
>> to select CC licenses. 
>> Rob Myers at Creative Commons is aware that some DSpace repositories have 
>> had an issue, but it's now past normal working hours, and I haven't been 
>> able to provide him with any useful information as to what's specifically 
>> causing the problem.
>>
>>
>> Disabling/enabling fixes nothing by the way.
>>>
>>> I had to comment out the CC License step in multiple locations in the 
>> item-submission.xml file on our test server, and then restart Tomcat. I 
>> think you are offering additional information that the CC License step 
>> still doesn't work once you enable it again.
>>
>>  
>>
>>> - Javier.
>>>
>>> El lunes, 2 de abril de 2018, 16:43:29 (UTC-5), Keith Gilbertson 
>>> escribió:

 George, we've had similar problems today. We'll probably disable CC 
 License steps for now, and then restart Tomcat. On our system, this is 
 configured in /dspace/conf/item-submission.xml
 --keith

 On Monday, April 2, 2018 at 5:31:29 PM UTC-4, George Kozak wrote:
>
> Hi,
> We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the CC 
> License submission step stopped working and caused an internal error.  I 
> don't use Twitter, but one of my co-workers who does saw Creative Commons 
> tweeted that their API was broken, but an hour later said it was back up. 
>  
> However, our DSpace installs are still failing at the CC License step.  I 
> tried rebooting my tomcat, but that didn't help.  Any suggestions?
>
> -- 
> ***
> George Kozak
> Digital Library Specialist
> Cornell University Library - IT
> 218 Olin Library
> Cornell University

[dspace-tech] Re: CC License step failing

[Javier Távara]

I saw the tweets. Thank you.

As we don't have any useful logs of what's happening, I thought 
disabling/enabling the step could fire any sort of cache clearing.

No success.

- Javier

El lunes, 2 de abril de 2018, 17:33:16 (UTC-5), Keith Gilbertson escribió:
>
>
>
> On Monday, April 2, 2018 at 6:18:47 PM UTC-4, Javier Távara wrote:
>>
>> I really don't want to disable the CC License step.
>>
>> That's understandable. Our repository team has been encouraging people to 
> select CC licenses. 
> Rob Myers at Creative Commons is aware that some DSpace repositories have 
> had an issue, but it's now past normal working hours, and I haven't been 
> able to provide him with any useful information as to what's specifically 
> causing the problem.
>
>
> Disabling/enabling fixes nothing by the way.
>>
>> I had to comment out the CC License step in multiple locations in the 
> item-submission.xml file on our test server, and then restart Tomcat. I 
> think you are offering additional information that the CC License step 
> still doesn't work once you enable it again.
>
>  
>
>> - Javier.
>>
>> El lunes, 2 de abril de 2018, 16:43:29 (UTC-5), Keith Gilbertson escribió:
>>>
>>> George, we've had similar problems today. We'll probably disable CC 
>>> License steps for now, and then restart Tomcat. On our system, this is 
>>> configured in /dspace/conf/item-submission.xml
>>> --keith
>>>
>>> On Monday, April 2, 2018 at 5:31:29 PM UTC-4, George Kozak wrote:

 Hi,
 We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the CC 
 License submission step stopped working and caused an internal error.  I 
 don't use Twitter, but one of my co-workers who does saw Creative Commons 
 tweeted that their API was broken, but an hour later said it was back up.  
 However, our DSpace installs are still failing at the CC License step.  I 
 tried rebooting my tomcat, but that didn't help.  Any suggestions?

 -- 
 ***
 George Kozak
 Digital Library Specialist
 Cornell University Library - IT
 218 Olin Library
 Cornell University
 Ithaca, NY 14853
 607-255-8924
 gs...@cornell.edu 

>>>

-- 
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.

[dspace-tech] Re: CC License step failing

[Javier Távara]

I really don't want to disable the CC License step.

Disabling/enabling fixes nothing by the way.

- Javier.

El lunes, 2 de abril de 2018, 16:43:29 (UTC-5), Keith Gilbertson escribió:
>
> George, we've had similar problems today. We'll probably disable CC 
> License steps for now, and then restart Tomcat. On our system, this is 
> configured in /dspace/conf/item-submission.xml
> --keith
>
> On Monday, April 2, 2018 at 5:31:29 PM UTC-4, George Kozak wrote:
>>
>> Hi,
>> We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the CC 
>> License submission step stopped working and caused an internal error.  I 
>> don't use Twitter, but one of my co-workers who does saw Creative Commons 
>> tweeted that their API was broken, but an hour later said it was back up.  
>> However, our DSpace installs are still failing at the CC License step.  I 
>> tried rebooting my tomcat, but that didn't help.  Any suggestions?
>>
>> -- 
>> ***
>> George Kozak
>> Digital Library Specialist
>> Cornell University Library - IT
>> 218 Olin Library
>> Cornell University
>> Ithaca, NY 14853
>> 607-255-8924
>> gs...@cornell.edu 
>>
>

-- 
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.

[dspace-tech] Re: CC License step failing

[Keith Gilbertson]

George, we've had similar problems today. We'll probably disable CC License 
steps for now, and then restart Tomcat. On our system, this is configured 
in /dspace/conf/item-submission.xml
--keith

On Monday, April 2, 2018 at 5:31:29 PM UTC-4, George Kozak wrote:
>
> Hi,
> We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the CC 
> License submission step stopped working and caused an internal error.  I 
> don't use Twitter, but one of my co-workers who does saw Creative Commons 
> tweeted that their API was broken, but an hour later said it was back up.  
> However, our DSpace installs are still failing at the CC License step.  I 
> tried rebooting my tomcat, but that didn't help.  Any suggestions?
>
> -- 
> ***
> George Kozak
> Digital Library Specialist
> Cornell University Library - IT
> 218 Olin Library
> Cornell University
> Ithaca, NY 14853
> 607-255-8924
> gs...@cornell.edu  
>

-- 
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.

[dspace-tech] Problems today with Creative Commons license and DSpace 5.X

[Keith Gilbertson]

Hi -

We experienced some problems with submissions at Virginia Tech today 
(DSpace 5.X, XMLUI, Creative Commons License Enabled, item-submission.xml 
style submission process). The submissions failed just before the Creative 
Commons License step. I don't have a stack trace because our system was 
purposely configured after an audit to make stack traces difficult to get.

On our test system, I'm able to successfully complete submissions by 
disabling CC License steps in item-submission.xml.

I'm wondering if others experienced similar problems today, or if it's just 
something peculiar to our configuration. Has anyone seen problems with CC 
Licenses recently?

If we see problems tomorrow, our workaround for now will be to disable CC 
Licenses. I know that others have dealt with changes to CC Licenses before 
- does anyone have ideas about how to troubleshoot our configuration, and 
if it's not our configuration, how to get CC Licenses working again?

Thanks,
Keith

-- 
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.

[dspace-tech] CC License step failing

[George Kozak]

Hi,
We have a DSpace 5.5 and a DSpace 6.2 install.  This afternoon, the CC
License submission step stopped working and caused an internal error.  I
don't use Twitter, but one of my co-workers who does saw Creative Commons
tweeted that their API was broken, but an hour later said it was back up.
However, our DSpace installs are still failing at the CC License step.  I
tried rebooting my tomcat, but that didn't help.  Any suggestions?

-- 
***
George Kozak
Digital Library Specialist
Cornell University Library - IT
218 Olin Library
Cornell University
Ithaca, NY 14853
607-255-8924
g...@cornell.edu

-- 
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] Re: DSpace 6.2 with collection home page too slow to load if items have lots of bitsteams

[Ying Jin]

Hi Tom,

Sorry for late reply. Somehow I missed your posting and just found it by
doing a search.

"would it be possible for any of you to provide an anonymised and cleaned
database that you can share with us? Make sure the database does not
contain any sensitive information. I'm sure such a database will also be
useful for other (demo and testing) purposes and the development of DSpace
7."

 Yes, I would love to have an anonymised and cleaned database to share
with you. I can't include everything we have, however, it would include
several collections that we are experiencing the performance problems. I am
wondering if it is easier sending them out as simple archive format and you
can ingest into whatever database you have?


"for the Collection and Community pages can you try setting the context
mode to READ_ONLY in the getValidity(), addPageMeta() and addBody() methods
of classes org.dspace.app.xmlui.aspect.artifactbrowser.CollectionViewer and
org.dspace.app.xmlui.aspect.artifactbrowser.CommunityViewer. Here's an
example of how to do that: https://github.com/DSpace/DSpace/pull/1694/files#
diff-fb7249e19a6a8652860795d8fd59cd9e"

 I will give it a try and see if it is indeed make any difference of
our problem. Although I think the ultimate solution might be to not loading
unnecessary objects (in our case, it may not necessary to load all the
bitstreams for a collection home page; )

"unfortunately the class responsible for the /community-list page already
uses the READ_ONLY mode (https://github.com/dspace/
DSpace/blob/dspace-6_x/dspace-xmlui/src/main/java/org/
dspace/app/xmlui/aspect/artifactbrowser/CommunityBrowser.java#L245). But
the fact that your number of (partial-)flushes is still so high, I wonder
if there is still another place hibernate is loading so many objects.
However as a workaround, you could enable caching of that /community-list
page by setting the xmlui.community-list.cache property in dspace.cfg to
true (https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/
config/dspace.cfg#L1917)."

 Is there any configuration for the cache of collection page? I thought
they are enabled by default but from the page loading, it doesn't seem like
the pages are cached ...

Best,
Ying


On Sun, Mar 11, 2018 at 5:39 PM, Tom Desair  wrote:

> Thanks all, this is really useful information!
>
> Since in both cases most time is lost on executing "flushes" or
> "partial-flushes", I think the problem is similar to
> https://jira.duraspace.org/browse/DS-3552: In AUTO mode
> 
> Hibernate keeps track of all objects loaded from the database and tries to
> "auto-save" them in the database before executing a new query. But the more
> objects Hibernate loads into its session, the more objects it needs to
> check for modification and possible interference with the new query that is
> being executed. Hence the more time it takes.
>
> *@Bill and @Ying*, would it be possible for any of you to provide an
> anonymised and cleaned database that you can share with us? Make sure the
> database does not contain any sensitive information. I'm sure such a
> database will also be useful for other (demo and testing) purposes and the
> development of DSpace 7.
>
> *@Ying*, for the Collection and Community pages can you try setting the
> context mode to READ_ONLY in the getValidity(), addPageMeta() and addBody()
> methods of classes 
> org.dspace.app.xmlui.aspect.artifactbrowser.CollectionViewer
> and org.dspace.app.xmlui.aspect.artifactbrowser.CommunityViewer. Here's
> an example of how to do that: https://github.com/
> DSpace/DSpace/pull/1694/files#diff-fb7249e19a6a8652860795d8fd59cd9e
>
> *@Bill*, unfortunately the class responsible for the /community-list page
> already uses the READ_ONLY mode (https://github.com/dspace/
> DSpace/blob/dspace-6_x/dspace-xmlui/src/main/java/org/
> dspace/app/xmlui/aspect/artifactbrowser/CommunityBrowser.java#L245). But
> the fact that your number of (partial-)flushes is still so high, I wonder
> if there is still another place hibernate is loading so many objects.
> However as a workaround, you could enable caching of that /community-list
> page by setting the xmlui.community-list.cache property in dspace.cfg to
> true (https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/
> config/dspace.cfg#L1917).
>
>
> Best regards,
> Tom
>
> [image: logo] Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> 
> Gaston Geenslaan 14, Leuven 3001, Belgium
> 
> www.atmire.com
> 
>
> 2018-03-11 22:43 GMT+01:00 Kim Shepherd :
>
>> Hi Bill and Ying, just a note to say I haven't managed to reproduce /
>> 

[dspace-tech] Is possible to backup/to delete items from workflow?

[Walter Blandón]

Hi everybody,

We have got several items in first step from workflow. We need a backup to 
this items before delete them. Is there some command line to do this task?

Is there some command line to delete items massively from workflow?


Many thanks.

Walter Blandón

-- 
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.