[Dspace-tech] new registries and upgrade process
Hello, while preparing to upgrade to 4.2 I thought about the upgrade process and registries. There have been a couple of new registries since 1.4.2: * worklfow-types.xml * sword-metadata.xml * dcterms-types.xml Registries [dspace-src]/dspace/config/registries/* are only loaded during ant fresh_install. Sometimes the upgrade installation included an extra step to load the registry (for sword-metadata.xml not for the others). So the new registries are usually not taken into account while doing an upgrade of an existing instance, unless they are loaded via the registry loader. So how can we avoid a discrepancy here, either bei adding an import descripion to the upgrade documentation or adding the new metadata values to the database upgrade scripts? Furthermore I think it would be best to have only one registry for metadata fields in order to avoid double declarations of fields like in dc-types.xml and sword-metadata.xml. Have a sunny day Claudia -- Claudia Juergen Eldorado Technische Universität Dortmund Universitätsbibliothek Vogelpothsweg 76 44227 Dortmund Tel.: +49 231-755 40 43 Fax: +49 231-755 40 32 claudia.juer...@ub.tu-dortmund.de www.ub.tu-dortmund.de -- ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] CC-license and HTTPS in JSPUI
Hi Pascal and all, I have found the failure and can explain, what went wrong. Now I have another problem in the same context, but at least I am one step further... The problem was the URL, which is embedded in the iframe (for JSPUI in webapps/jspui/submit/creative-commons.jsp). Here is referenced: http(s)://creativecommons.org/license/?partner=dspace. The path /license/ redirects to /choose/, but this redirection switches the protocol from whatever it was to HTTP. Thats why Firefox is complaining about mixed content, no matter what is referenced in the iframe. To solve that I changed the path of the embedded URL from /license/ to /choose/. This works and I can select a CC-license. BUT: clicking on the continue button on the next page gets me to an internal error page and the license is not stored. Looking into the logfile, I see this error: 2014-08-14 16:52:55,985 ERROR org.dspace.app.webui.servlet.SubmissionController @ Error loading step class'org.dspace.submit.step.CCLicenseStep': java.io.IOException: File or directory not found I thought selecting the license was the CCLicenseStep?! Any ideas how to fix this? Best Oliver Am 30.07.2014 um 11:44 schrieb Becker, Pascal-Nicolas: Hi Oliver, I just read your mail from yesterday again. If I understand correctly it works sometimes and sometimes not. May this be a cache problem? If you are using XMLUI you should clean it's cache as well as the browser cache. This is just a bold guess, but may be worth to clean all caches and try your solution once again... Even if it is not a DSpace issue can you please repot a solution if you find one? Regards, Pascal -Original Message- From: Oliver Goldschmidt [mailto:o.goldschm...@tuhh.de] Sent: Wednesday, July 30, 2014 11:23 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] CC-license and HTTPS in JSPUI Hi, I was able to solve this issue - at least for Firefox. As described here [1], you can leave out the protocol and reference ambedded external websites with //example.org. Doing that, its referenced via the same protocol as the embedding page. Unfortunately, this only works with Firefox (definitely not with Chromium, havent tried it with IE yet). Though, a compatible solution for all browsers of course would be more appropriate... But this is obviously not a DSpace issue, so I will stop reporting it here. Best regards Oliver [1] https://developer.mozilla.org/en- US/docs/Security/MixedContent/How_to_fix_website_with_mixed_conten t Am 30.07.2014 um 10:05 schrieb Oliver Goldschmidt: Hi again, I now retried what I described yesterday in a different browser (yesterday it was Firefox, today I am trying Chromium) to see if my HTTPS-CC-issue is reproducable there. Answer: it is reproducable, and its even worse. Although I am referencing https://creativecommons.org/choose/?partner=dspace(...) , I get that error message: [blocked] The page at 'https://xyz.tuhh.de/submit' was loaded over HTTPS, but ran insecure content from 'http://creativecommons.org/choose/?partner=dspace(...)': this content should also be loaded over HTTPS. In Chromium, the problem is already on the cc-licence-page: the iframe is white without any content. Any ideas? Best regards Oliver Am 29.07.2014 um 17:19 schrieb Oliver Goldschmidt: Hello all, I have a very weird problem with creativecommons.org and DSpace. Perhaps anyone here has an idea about that. The scenario is the following: I have DSpace configured, that its always loaded over HTTPS (by redirecting any call to Port 443). That works fine. But coming to the publication there is a problem. I have also enabled the CC-license step. As I reached that step in the publication process, I only got a white page inside the cc-iframe. I figured out, why that happened: a URL at creativecommons.org is embedded in an iframe, and loading a normal HTTP-URL in a HTTPS page iframe is forbidden. Though, I changed the URL of creativecommons.org in submit/creative-commons.jsp to its HTTPS-equivalent: https://creativecommons.org/choose/?partner=dspace. Now it worked and I got the creativecommons-page inside the iframe. But something is still wrong: I cannot select a license. Its getting blocked, because the browser is still getting mixed content. Obviously the creativecommons.org-page is not loaded via HTTPS, but via HTTP, although the URL points to HTTPS (and is displayed in the HTTPS-iframe, while its not displayed using the HTTP-URL). I can even reproduce this: clicking on the link https://creativecommons.org/choose/?partner=dspace gets me to the unencrypted version of the page. Only when I manually edit the URL in my browser window, I get to the real HTTPS address. Thats really odd... Perhaps someone can reproduce that or has an idea how to fix that. Any hints are appreciated! Best regards Oliver - -
Re: [Dspace-tech] CC-license and HTTPS in JSPUI
Hi again, it must have been a cache proplem or a problem with this specific document: I cannot reproduce the CCLicenseStep-Error. For new submissions it works fine. Perhaps someone can correct the URL in webapps/jspui/submit/creative-commons.jsp in the master to solve the problem in the next version? Best regards Oliver Am 14.08.2014 um 16:57 schrieb Oliver Goldschmidt: Hi Pascal and all, I have found the failure and can explain, what went wrong. Now I have another problem in the same context, but at least I am one step further... The problem was the URL, which is embedded in the iframe (for JSPUI in webapps/jspui/submit/creative-commons.jsp). Here is referenced: http(s)://creativecommons.org/license/?partner=dspace. The path /license/ redirects to /choose/, but this redirection switches the protocol from whatever it was to HTTP. Thats why Firefox is complaining about mixed content, no matter what is referenced in the iframe. To solve that I changed the path of the embedded URL from /license/ to /choose/. This works and I can select a CC-license. BUT: clicking on the continue button on the next page gets me to an internal error page and the license is not stored. Looking into the logfile, I see this error: 2014-08-14 16:52:55,985 ERROR org.dspace.app.webui.servlet.SubmissionController @ Error loading step class'org.dspace.submit.step.CCLicenseStep': java.io.IOException: File or directory not found I thought selecting the license was the CCLicenseStep?! Any ideas how to fix this? Best Oliver Am 30.07.2014 um 11:44 schrieb Becker, Pascal-Nicolas: Hi Oliver, I just read your mail from yesterday again. If I understand correctly it works sometimes and sometimes not. May this be a cache problem? If you are using XMLUI you should clean it's cache as well as the browser cache. This is just a bold guess, but may be worth to clean all caches and try your solution once again... Even if it is not a DSpace issue can you please repot a solution if you find one? Regards, Pascal -Original Message- From: Oliver Goldschmidt [mailto:o.goldschm...@tuhh.de] Sent: Wednesday, July 30, 2014 11:23 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] CC-license and HTTPS in JSPUI Hi, I was able to solve this issue - at least for Firefox. As described here [1], you can leave out the protocol and reference ambedded external websites with //example.org. Doing that, its referenced via the same protocol as the embedding page. Unfortunately, this only works with Firefox (definitely not with Chromium, havent tried it with IE yet). Though, a compatible solution for all browsers of course would be more appropriate... But this is obviously not a DSpace issue, so I will stop reporting it here. Best regards Oliver [1] https://developer.mozilla.org/en- US/docs/Security/MixedContent/How_to_fix_website_with_mixed_conten t Am 30.07.2014 um 10:05 schrieb Oliver Goldschmidt: Hi again, I now retried what I described yesterday in a different browser (yesterday it was Firefox, today I am trying Chromium) to see if my HTTPS-CC-issue is reproducable there. Answer: it is reproducable, and its even worse. Although I am referencing https://creativecommons.org/choose/?partner=dspace(...) , I get that error message: [blocked] The page at 'https://xyz.tuhh.de/submit' was loaded over HTTPS, but ran insecure content from 'http://creativecommons.org/choose/?partner=dspace(...)': this content should also be loaded over HTTPS. In Chromium, the problem is already on the cc-licence-page: the iframe is white without any content. Any ideas? Best regards Oliver Am 29.07.2014 um 17:19 schrieb Oliver Goldschmidt: Hello all, I have a very weird problem with creativecommons.org and DSpace. Perhaps anyone here has an idea about that. The scenario is the following: I have DSpace configured, that its always loaded over HTTPS (by redirecting any call to Port 443). That works fine. But coming to the publication there is a problem. I have also enabled the CC-license step. As I reached that step in the publication process, I only got a white page inside the cc-iframe. I figured out, why that happened: a URL at creativecommons.org is embedded in an iframe, and loading a normal HTTP-URL in a HTTPS page iframe is forbidden. Though, I changed the URL of creativecommons.org in submit/creative-commons.jsp to its HTTPS-equivalent: https://creativecommons.org/choose/?partner=dspace. Now it worked and I got the creativecommons-page inside the iframe. But something is still wrong: I cannot select a license. Its getting blocked, because the browser is still getting mixed content. Obviously the creativecommons.org-page is not loaded via HTTPS, but via HTTP, although the URL points to HTTPS (and is displayed in the HTTPS-iframe, while its not displayed using the HTTP-URL). I can even reproduce this: clicking on the link
