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

[jca3]

Hi everyone,

Does anyone is having some problem with CC again? In my repository the cc 
step just show "no license" option.

Thanks.

Em segunda-feira, 2 de julho de 2018 17:05:00 UTC-3, Javier Távara escreveu:
>
> Hi Rob!
> Our DSpace instances are having problems again due to an invalid SSL cert.
>
> I hope you can take a look soon.
>
> Disabling CC step in DSpace meanwhile...
>
> Thank you!
>
> Javier.
>
>
> El martes, 3 de abril de 2018, 16:05:02 (UTC-5), Rob Myers escribió:
>>
>> Thank you everyone who reported this.
>>
>> I am going to mark this as fixed.
>>
>> We should move the API to https-only at some point in the future to help 
>> keep user information private, but it shouldn't happen without warning.
>>
>> Thanks again.
>>
>> - Rob.
>>
>> On Tuesday, April 3, 2018 at 11:34:44 AM UTC-7, George Kozak wrote:
>>>
>>> Rob:
>>> Thank you.  Going back to http has fixed the problem for us at Cornell 
>>> University.
>>> George Kozak
>>> Cornell University
>>>
>>> On Tue, Apr 3, 2018 at 2:01 PM, Rob Myers  
>>> wrote:
>>>
 Heya all.

 I have re-enabled http for now. I will put a redirect back in place at 
 some point in the future, with suitable warning.

 For anyone who changing the url to be https didn't help, does switching 
 back to http improve things?

 - Rob.

 On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
>
> 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 
>>> licen

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

[Rob Myers]

Thank you everyone who reported this.

I am going to mark this as fixed.

We should move the API to https-only at some point in the future to help 
keep user information private, but it shouldn't happen without warning.

Thanks again.

- Rob.

On Tuesday, April 3, 2018 at 11:34:44 AM UTC-7, George Kozak wrote:
>
> Rob:
> Thank you.  Going back to http has fixed the problem for us at Cornell 
> University.
> George Kozak
> Cornell University
>
> On Tue, Apr 3, 2018 at 2:01 PM, Rob Myers  > wrote:
>
>> Heya all.
>>
>> I have re-enabled http for now. I will put a redirect back in place at 
>> some point in the future, with suitable warning.
>>
>> For anyone who changing the url to be https didn't help, does switching 
>> back to http improve things?
>>
>> - Rob.
>>
>> On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
>>>
>>> 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 res

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

[George Kozak]

Rob:
Thank you.  Going back to http has fixed the problem for us at Cornell
University.
George Kozak
Cornell University

On Tue, Apr 3, 2018 at 2:01 PM, Rob Myers  wrote:

> Heya all.
>
> I have re-enabled http for now. I will put a redirect back in place at
> some point in the future, with suitable warning.
>
> For anyone who changing the url to be https didn't help, does switching
> back to http improve things?
>
> - Rob.
>
> On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
>>
>> 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=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://creativec
 ommons.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://creativec
 ommons.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 >>> xmlns:cc="http://creativecommons.org/ns#"; href="
 https://example.com/untitled"; property="cc:attributionName"
 rel="cc:attributionURL">A. N. Other is licensed under a >>> rel="license" href="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 cach

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

[Javier Távara]

Thanks Rob, definitely the best choice.

I see the API is back online.

— Javier T.

On Apr 3, 2018, 1:04 PM -0500, Rob Myers , wrote:
> Heya all.
>
> I have re-enabled http for now. I will put a redirect back in place at some 
> point in the future, with suitable warning.
>
> For anyone who changing the url to be https didn't help, does switching back 
> to http improve things?
>
> - Rob.
>
> On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
> > 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. Other > > > rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/"/> > > >  rdf:about="http://creativecommons.org/licenses/by-sa/4.0/";>
> > > >      > > > rdf:resource="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/";>
> > > >      > > > rdf:resource="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"/>
> > > >   
> > > > 
> > > >   
> > > >    > > > href="http://creativecommons.org/licenses/by-sa/4.0/";> > > > alt="Creative Commons License" style="border-width:0" 
> > > > src="http://i.creativecommons.org/l/by-sa/4.0/88x31.png"/> > > >  xmlns:dct="http://purl.org/dc/terms/"; 
> > > > property="dct:title">Untitled by  > > > xmlns:cc="http://creativecommons.org/ns#"; 
> > > > href="https://example.com/untitled"; property="cc:attributionName" 
> > > > rel="cc:attributionURL">A. N. Other is licensed under a  > > > rel="license" 
> > > > href="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 

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

[amgciadev]

Hi again,

Yes we do too due to the CC API service being down. Before, changing the 
configuration file alone to "https" worked while the API was still 
available - just in case this is useful to people.

Agustina

On Tuesday, 3 April 2018 13:41:14 UTC+1, Marion Rupp wrote:
>
> Hi,
>
> We still have failure with CC, too (DSpace Version 6.2). 
>
> At the momentan, the CC API at https://api.creativecommons.org/rest/1.5 
> is not available (503 error).
>
> Kind regards,
> Marion
>
> ---
> Marion Rupp
> Bibliotheks-IT
> Universitäts- und Landesbibliothek Bonn
> Postfach 2460, D-53014 Bonn
> Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
> eMail: mario...@ulb.uni-bonn.de 
> Internet: http://www.ulb.uni-bonn.de
> Twitter: http://twitter.com/ulbbonn
> Facebook: http://facebook.com/ulbbonn
>
> Am 03.04.2018 um 02:49 schrieb 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=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 G

[dspace-tech] Re: CC License step failing

[Rob Myers]

Heya all.

I have re-enabled http for now. I will put a redirect back in place at some 
point in the future, with suitable warning.

For anyone who changing the url to be https didn't help, does switching 
back to http improve things?

- Rob.

On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
>
> 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 

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

[Javier Távara]

George,
It depends on where you are doing the change. See 
https://wiki.duraspace.org/display/DSPACE/Rebuild+DSpace and 
https://wiki.duraspace.org/display/DSDOC5x/Ant+targets+and+options

I only make changes to [dspace-source], so I have to rebuild it for the new 
config to be copied to [dspace] installation directory.

I saved this as config-update.sh to make things faster:

cd /home/dspace/source-5.5/dspace
mvn package -P !dspace-jspui,!dspace-sword,!dspace-swordv2,!dspace-rdf
cd /home/dspace/source-5.5/dspace/target/dspace-installer
ant update_configs
service tomcat restart

I hope I'm not doing unnecessary stuff.

— Javier T.

On Apr 3, 2018, 12:19 PM -0500, George Kozak , wrote:
> Javier:
> On my DSpace 5.5 instance, I made the change you noted to https in the 
> dspace.cfg file and restarted tomcat.  On my DSpace 6.2 instance, I made the 
> change in the local.cfg file and restarted tomcat, but in both cases, nothing 
> changed.  I couldn't reconnect.
>
> I see in your email that you mentioned recompiling.  Do you mean going 
> through the Maven and ant process all over again after this change is made?
> George Kozak
> Cornell University
>
> > On Tue, Apr 3, 2018 at 9:52 AM, Javier Távara  wrote:
> > > Rob,
> > > The change is easy, at least for the most common DSpace installations, 
> > > but it will break a lot of instances probably. It must be done at any 
> > > time in the future though.
> > >
> > > George,
> > > Are you sure you recompiled DSpace correctly? The API was online when you 
> > > posted.
> > >
> > > CC API is down since 8:41 UTC (I started monitoring it yesterday 
> > > https://goo.gl/xEwLjn).
> > > Meanwhile, I will better disable the CC License step until everything is 
> > > back stable.
> > >
> > > - Javier.
> > >
> > > El martes, 3 de abril de 2018, 7:41:14 (UTC-5), Marion Rupp escribió:
> > > > Hi,
> > > >
> > > > We still have failure with CC, too (DSpace Version 6.2).
> > > >
> > > > At the momentan, the CC API at https://api.creativecommons.org/rest/1.5 
> > > > is not available (503 error).
> > > >
> > > > Kind regards,
> > > > Marion
> > > >
> > > > ---
> > > > Marion Rupp
> > > > Bibliotheks-IT
> > > > Universitäts- und Landesbibliothek Bonn
> > > > Postfach 2460, D-53014 Bonn
> > > > Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
> > > > eMail: mario...@ulb.uni-bonn.de
> > > > Internet: http://www.ulb.uni-bonn.de
> > > > Twitter: http://twitter.com/ulbbonn
> > > > Facebook: http://facebook.com/ulbbonn
> > > > Am 03.04.2018 um 02:49 schrieb 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=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. Other > > > > > > > rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/"/> > > > > > > >  rdf:about="http://creativecommons.org/licenses/by-sa/4.0/";>
> > > > > > > >      > > > > > > > rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
> > > > > > > >    

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

[George Kozak]

Javier:
On my DSpace 5.5 instance, I made the change you noted to https in the
dspace.cfg file and restarted tomcat.  On my DSpace 6.2 instance, I made
the change in the local.cfg file and restarted tomcat, but in both cases,
nothing changed.  I couldn't reconnect.

I see in your email that you mentioned recompiling.  Do you mean going
through the Maven and ant process all over again after this change is made?
George Kozak
Cornell University

On Tue, Apr 3, 2018 at 9:52 AM, Javier Távara  wrote:

> Rob,
> The change is easy, at least for the most common DSpace installations, but
> it will break a lot of instances probably. It must be done at any time in
> the future though.
>
> George,
> Are you sure you recompiled DSpace correctly? The API was online when you
> posted.
>
> CC API is down since 8:41 UTC (I started monitoring it yesterday
> https://goo.gl/xEwLjn).
> Meanwhile, I will better disable the CC License step until everything is
> back stable.
>
> - Javier.
>
> El martes, 3 de abril de 2018, 7:41:14 (UTC-5), Marion Rupp escribió:
>>
>> Hi,
>>
>> We still have failure with CC, too (DSpace Version 6.2).
>>
>> At the momentan, the CC API at https://api.creativecommons.org/rest/1.5
>> is not available (503 error).
>>
>> Kind regards,
>> Marion
>>
>> ---
>> Marion Rupp
>> Bibliotheks-IT
>> Universitäts- und Landesbibliothek Bonn
>> Postfach 2460, D-53014 Bonn
>> Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
>> eMail: mario...@ulb.uni-bonn.de
>> Internet: http://www.ulb.uni-bonn.de
>> Twitter: http://twitter.com/ulbbonn
>> Facebook: http://facebook.com/ulbbonn
>>
>> Am 03.04.2018 um 02:49 schrieb 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://creativec
 ommons.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://creativec
 ommons.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 >>> xmlns:cc="http://creativecommons.org/ns#"; href="
 https://example.com/untitled"; property="cc:attributionName"
 rel="cc:attributionURL">A. N. Other is licensed under a >>> rel="license" href="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
 ce

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

[Javier Távara]

Rob, 
The change is easy, at least for the most common DSpace installations, but 
it will break a lot of instances probably. It must be done at any time in 
the future though.

George,
Are you sure you recompiled DSpace correctly? The API was online when you 
posted.

CC API is down since 8:41 UTC (I started monitoring it yesterday 
https://goo.gl/xEwLjn).
Meanwhile, I will better disable the CC License step until everything is 
back stable.

- Javier.

El martes, 3 de abril de 2018, 7:41:14 (UTC-5), Marion Rupp escribió:
>
> Hi,
>
> We still have failure with CC, too (DSpace Version 6.2). 
>
> At the momentan, the CC API at https://api.creativecommons.org/rest/1.5 
> is not available (503 error).
>
> Kind regards,
> Marion
>
> ---
> Marion Rupp
> Bibliotheks-IT
> Universitäts- und Landesbibliothek Bonn
> Postfach 2460, D-53014 Bonn
> Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
> eMail: mario...@ulb.uni-bonn.de 
> Internet: http://www.ulb.uni-bonn.de
> Twitter: http://twitter.com/ulbbonn
> Facebook: http://facebook.com/ulbbonn
>
> Am 03.04.2018 um 02:49 schrieb 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=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. 

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

[Javier Távara]

(Posting this again because somehow messages are being deleted by mistake 
or false spam alarm)

Rob, 
The change is easy, at least for the most common DSpace installations, but 
it will break a lot of instances probably. It must be done at any time in 
the future though.

George,
Are you sure you recompiled DSpace correctly? The API was online when you 
posted.

CC API is down since 8:41 UTC.
Meanwhile, I will better disable the CC License step until everything is 
back stable.

- Javier.

El martes, 3 de abril de 2018, 7:41:14 (UTC-5), Marion Rupp escribió:
>
> Hi,
>
> We still have failure with CC, too (DSpace Version 6.2). 
>
> At the momentan, the CC API at https://api.creativecommons.org/rest/1.5 
> is not available (503 error).
>
> Kind regards,
> Marion
>
> ---
> Marion Rupp
> Bibliotheks-IT
> Universitäts- und Landesbibliothek Bonn
> Postfach 2460, D-53014 Bonn
> Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
> eMail: mario...@ulb.uni-bonn.de 
> Internet: http://www.ulb.uni-bonn.de
> Twitter: http://twitter.com/ulbbonn
> Facebook: http://facebook.com/ulbbonn
>
> Am 03.04.2018 um 02:49 schrieb 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=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: 
>>

[dspace-tech] Re: CC License step failing

[Nicholas Woodward]

I think there are still some issues on the CC side. The curl command from 
Rob's message above responds with a 503 Service Unavailable. Same for just 
https://api.creativecommons.org/rest/1.5. Our DSpace is still giving the 
NullPointerException.


On Tuesday, April 3, 2018 at 3:43:37 AM UTC-5, amgc...@gmail.com wrote:
>
> Hi all,
>
> We have also performed the change to HTTPS for the cc.api.rooturl 
> configuration parameter and restarted DSpace (v5.6) and everything seems to 
> be working again.
>
> Best,
> Agustina
>
> On Monday, 2 April 2018 22:31:29 UTC+1, 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.

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

[Marion Rupp]

Hi,

We still have failure with CC, too (DSpace Version 6.2).

At the momentan, the CC API at https://api.creativecommons.org/rest/1.5 
 is not available (503 error).


Kind regards,
Marion

---
Marion Rupp
Bibliotheks-IT
Universitäts- und Landesbibliothek Bonn
Postfach 2460, D-53014 Bonn
Tel. 0228 / 73 75 50 Fax: 0228 / 73 75 46
eMail: marion.r...@ulb.uni-bonn.de
Internet: http://www.ulb.uni-bonn.de
Twitter: http://twitter.com/ulbbonn
Facebook: http://facebook.com/ulbbonn

Am 03.04.2018 um 02:49 schrieb 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=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

[dspace-tech] Re: CC License step failing

[amgciadev]

Hi all,

We have also performed the change to HTTPS for the cc.api.rooturl 
configuration parameter and restarted DSpace (v5.6) and everything seems to 
be working again.

Best,
Agustina

On Monday, 2 April 2018 22:31:29 UTC+1, 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.

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 (UTC-5), Kei

[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 tes

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

[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 Uni

[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

[Keith Gilbertson]

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] Re: CC License step failing

[Nicholas Woodward]

Our DSpace instances are in the same situation. Like you said, the CC 
Twitter account says the API is back up, but we still get a 
NullPointerException when contacting it.

 

On Monday, April 2, 2018 at 4:31:29 PM UTC-5, 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.