[dspace-tech] Re: Suddenly Sword Says "Unauthorized Credentials"

2019-01-24 Thread librarysystems . test
Further information:

We seem to have got past "unauthorized credentials."

Now Vireo says, "Unable to communicate with deposit location: 
org.purl.sword.client.SWORDClientException: Received error from service 
document request: Code: 400, Message: 'Bad Request'

Using curl to browse to the Sword servicedocument URL gives this message: "The 
requested URL /sword/servicedocument was not found on this server."

Browsing to the same URL in Internet Explorer gives this message:  HTTP 
Status 400 – Bad Request
--

*Type* Status Report

*Message* Unable to recognise URL as a valid service document: 
https://rctest.ourschool.edu/sword/servicedocument

*Description* The server cannot or will not process the request due to 
something that is perceived to be a client error (e.g., malformed request 
syntax, invalid request message framing, or deceptive request routing).
--
Apache Tomcat/7.0.90
- show quoted text -

On Wednesday, January 23, 2019 at 10:55:26 AM UTC-6, librarysy...@gmail.com 
wrote:
>
> We are using Vireo 3.0.6 (with Sword v1) and publishing to a DSpace 6.3 
> repository.  Since updating the operating systems on both servers, Vireo 
> can’t connect to the DSpace repository to deposit theses and 
> dissertations.  The DSpace server is running Amazon Linux kernel 
> 4.14.88-72.73.amzn1.x86_64, Tomcat 7 and Apache 2.2.  At first, the error 
> message indicated a certificate error.  I replaced the cacerts files and 
> the operating system CA files with the ones that existed prior to the 
> update.  That fixed the certificate error, but now we get “unauthorized 
> credentials” when testing the connection.  I tested the credentials by 
> logging into the DSpace server’s web interface, and they are correct.  User 
> permissions have not changed, so the deposit user should be authorized.
>
>
> I also tested by browsing to the Sword servicedocument page.  The page 
> produces a login box.  When I enter the credentials, the login box 
> disappears, then reappears.  I don't know how to interpret this.  The 
> Tomcat log records 401 errors.
>
>
> I'm out of ideas for troubleshooting, would appreciate any suggestions.
>
>
> Glenn
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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: Suddenly Sword Says "Unauthorized Credentials"

2019-01-24 Thread librarysystems . test
Further information:

We seem to have got past "unauthorized credentials."

Now Vireo says, "Unable to communicate with deposit location: 
org.purl.sword.client.SWORDClientException: Received error from service 
document request: Code: 400, Message: 'Bad Request'

Using curl to browse to the Sword servicedocument URL gives this message: "The 
requested URL /uta-sword/servicedocument was not found on this server."

Browsing to the same URL in Internet Explorer gives this message:  HTTP 
Status 400 – Bad Request
--

*Type* Status Report

*Message* Unable to recognise URL as a valid service document: 
https://rctest.ourschool.edu/sword/servicedocument

*Description* The server cannot or will not process the request due to 
something that is perceived to be a client error (e.g., malformed request 
syntax, invalid request message framing, or deceptive request routing).
--
Apache Tomcat/7.0.90
On Wednesday, January 23, 2019 at 10:55:26 AM UTC-6, librarysy...@gmail.com 
wrote:
>
> We are using Vireo 3.0.6 (with Sword v1) and publishing to a DSpace 6.3 
> repository.  Since updating the operating systems on both servers, Vireo 
> can’t connect to the DSpace repository to deposit theses and 
> dissertations.  The DSpace server is running Amazon Linux kernel 
> 4.14.88-72.73.amzn1.x86_64, Tomcat 7 and Apache 2.2.  At first, the error 
> message indicated a certificate error.  I replaced the cacerts files and 
> the operating system CA files with the ones that existed prior to the 
> update.  That fixed the certificate error, but now we get “unauthorized 
> credentials” when testing the connection.  I tested the credentials by 
> logging into the DSpace server’s web interface, and they are correct.  User 
> permissions have not changed, so the deposit user should be authorized.
>
>
> I also tested by browsing to the Sword servicedocument page.  The page 
> produces a login box.  When I enter the credentials, the login box 
> disappears, then reappears.  I don't know how to interpret this.  The 
> Tomcat log records 401 errors.
>
>
> I'm out of ideas for troubleshooting, would appreciate any suggestions.
>
>
> Glenn
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


RE: [dspace-tech] Re: Dspace 5.6 to 6.3 database migration problem

2019-01-24 Thread Khanh M. Mai
x-uw-ex-currentlocation-365-recipient: Outside
x-microsoft-antispam-prvs: 

x-forefront-prvs: 0927AA37C7
x-forefront-antispam-report: 
SFV:NSPM;SFS:(10009020)(3986042)(396003)(366004)(136003)(346002)(376002)(189003)(199004)(40764003)(6306002)(7696005)(97736004)(7736002)(486006)(33656002)(76176011)(93886005)(106356001)(86362001)(446003)(236005)(9686003)(68736007)(105586002)(8676002)(54896002)(110136005)(53936002)(26005)(88552002)(14454004)(186003)(81156014)(66066001)(966005)(102836004)(81166006)(55016002)(47861)(53546011)(74316002)(2906002)(6116002)(75432002)(7120041)(7119041)(316002)(606006)(786003)(6246003)(25786009)(3906042)(6436002)(8936002)(79071)(229853002)(99286004)(476003)(6506007)(11346002)(3846002)(256004)(1005);DIR:OUT;SFP:1101;SCL:1;SRVR:MWHPR08MB2990;H:MWHPR08MB2863.namprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: uw.edu does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 
s8QSKgxQA+p5NdgiMzae3l1bfVLgXg36YSTL+WULRq3DTPuzVl+hJouUuBOPlLIR8n7YSxFhWOuEbGc9dYcLMM+KeYvXrSsUKs3NmEIsIxVahzNOV908yY4i/lNbBkHqdVkrCoQNPYr3V34AfMZCd4gD/aCz9tGRdUpfo5PZlmCoSkwk7dt3SZx/QXctBCbEw5ALoPGwYoA7kuqBeRe1b0EPdzX16jCWBnjxvoITdTJgfnysZFCmdKixNHKySf5rgr0j7RYDPPWKzdrDyfdPIzb8kpPswXJqeDalexbhHS2eM40+4etPiDqEC31o5ibuR2UFapb42PZYcIKrcptCjGdZGifJ3WEypYjUtgsfQPOuFoBPPxR/uC1Shl3XqUE5fKp97qLsBxmubTXpI+2gGcH2E/LvV2L1yVB/AoeBcp0=
Content-Type: multipart/alternative;
boundary="_000_MWHPR08MB2863C2D2EF05F6D2191E35C9A49A0MWHPR08MB2863namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 
300d3327-fb5d-420f-40c0-08d6823ad147
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 20:30:44.7053
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f6b6dd5b-f02f-441a-99a0-162ac5060bd2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2990
X-OriginatorOrg: uw.edu
X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 
2019.1.24.202416, AntiVirus-Engine: 5.56.1, AntiVirus-Data: 2019.1.24.5561004
X-PMX-Server: mxout25.s.uw.edu
X-Uwash-Spam: Gauge=, Probability=8%, Report='
 HTML_70_90 0.1, KNOWN_FREEWEB_URI 0.05, SUPERLONG_LINE 0.05, 
BODYTEXTH_SIZE_3000_MORE 0, BODY_SIZE_1_PLUS 0, DKIM_SIGNATURE 0, 
ECARD_KNOWN_DOMAINS 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, 
MSG_THREAD 0, REFERENCES 0, SPF_NEUTRAL 0, URI_WITH_PATH_ONLY 0, WEBMAIL_SOURCE 
0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, 
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CANPHARM_UNSUB_LINK 0, __CP_URI_IN_BODY 0, __CT 
0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, 
__DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FUR_RDNS_OUTLOOK 0, __HAS_FROM 0, __HAS_HTML 
0, __HAS_MSGID 0, __HAS_XOIP 0, __HTML_FONT_BLUE 0, __HTML_TAG_DIV 0, 
__HTTPS_URI 0, __INVOICE_MULTILINGUAL 0, __IN_REP_TO 0, __KNOWN_FREEWEB_URI3 0, 
__KNOWN_FREEWEB_URI5 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, 
__MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0,
 __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_SUBJ_ALERT 0, 
__RDNS_WEBMAIL 0, __REFERENCES 0, __SANE_MSGID 0, __STYLE_RATWARE_NEG 0, 
__STYLE_TAG 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, 
__TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 
0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NO_WWW 0, 
__URI_NS , __URI_WITH_PATH 0'
X-Original-Sender: khanh...@uw.edu
X-Original-Authentication-Results: gmr-mx.google.com;   dkim=pass
 header.i=@uwnetid.onmicrosoft.com header.s=selector1-uw-edu
 header.b=OxnnsaKH;   spf=pass (google.com: domain of khanh...@uw.edu
 designates 140.142.234.175 as permitted sender) smtp.mailfrom=khanh...@uw.edu
Precedence: list
Mailing-list: list dspace-tech@googlegroups.com; contact 
dspace-tech+own...@googlegroups.com
List-ID: 
X-Spam-Checked-In-Group: dspace-tech@googlegroups.com
X-Google-Group-Id: 67288969863
List-Post: , 

List-Help: , 

List-Archive: , 

List-Unsubscribe: 
,
 
X-MXTHUNDER-Identifier:  

X-MXTHUNDER-IP-Rating:  1, 140.142.234.175, Ugly c=0.285716 p=-0.125 Source 
Normal
X-MXTHUNDER-Scan-Result:  0
X-MXTHUNDER-Rules: 
0-0-0-32767-c
X-MXTHUNDER-Clean:  Yes
X-MXTHUNDER-Group:  OK

--_000_MWHPR08MB2863C2D2EF05F6D2191E35C9A49A0MWHPR08MB2863namp_
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This upgrade is on a test machine 

Re: [dspace-tech] How to merger two collections into one?

2019-01-24 Thread Stan Orlov
Many  thanks, Alan!

That makes it much clearer.  After reading your reply, I examined our setup 
more closely together with our Archivist, who explained to me the process 
she uses to submit the Theses.  Turned out that she puts everything into 
the main Graduate Theses collection and then maps each item to the 
collection of the department where the student wrote the theses.  So, each 
item has two entries like this:

Graduate Theses
Department of Education - Graduate Theses

It's just that for the Applied Human Nutrition items it looked like this:

Graduate Theses
Graduate Theses

Thanks to you, we figured out that every thesis is mapped, we just needed 
to rename one collection, so we now have:

Graduate Theses
Applied Human Nutrition - Graduate Theses

And, of course, as you point out, the Handle links do not change, so we are 
golden!  Another crisis averted :)

>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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] DC, QDC, and DCTERMS: reviewing our metadata practices

2019-01-24 Thread Alan Orth
Dear list,

We have started looking at our use of metadata across our repositories and
I have to say that it is very confusing! First some background as I
understand it, then the current state of affairs in DSpace 4/5/6, and then
my question(s). :)

Dublin Core is the original specification of fifteen elements from 1995[0].
It was amended in 2000 to add element qualifiers like "dc.date.issued" as
well as a few new elements[1]. These were both superseded in 2008 with the
introduction of the Dublin Core Terms (aka DCTERMS) specification[2], which
essentially combines both of them.

By default DSpace makes heavy use of both simple and qualified Dublin Core
in its input forms, but also provides crosswalks to translate many of these
to DCTERMS that are then exposed as metadata in the XMLUI[3][4]. It is very
easy to change the input forms to use different fields and even custom
namespaces, though some core fields seem to be dangerous (like dc.date.*
and dc.contributor.author).

Our repository is consumed ravenously by search engines, but also by
increasingly many harvesters via REST and OAI APIs. If we want to make sure
that the metadata these harvesters receive is also standards compliant and
interoperable, shouldn't we update our input-forms and existing item
metadata to take some of the crosswalks into mind? For example: to start
using dc.language or dcterms.language instead of dc.language.iso (I would
of course update the crosswalks accordingly). Does any of this change in
DSpace 7? Is there any talk of moving away from a flat schema so that
authors and institutions could be related, for example?

I look forward to your comments. Thank you.

[0] https://en.wikipedia.org/wiki/Dublin_Core
[1] http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/
[2] http://www.dublincore.org/documents/dcmi-terms/
[3]
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/crosswalks/xhtml-head-item.properties
[4]
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/crosswalks/google-metadata.properties

-- 
Alan Orth
alan.o...@gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


Re: [dspace-tech] Re: Dspace 5.6 to 6.3 database migration problem

2019-01-24 Thread Mark H. Wood
On Wednesday, January 23, 2019 at 7:12:07 PM UTC-5, Khanh M. Mai wrote:
>
> I was connecting to my database through a proxy.  This time I set my 
> dspace install to connect directly to the the postgres instance. 
>
>  
>
> The error now is regarding CREATE TABLE dspaceobject
>
>  
>
> Am I doing my import correctly? Are there any special flags for the 
> pg_dump I need to add?
>   
>
> [root@rworks61 dspace]# bin/dspace database migrate
>
>  
>
> Database URL: jdbc:postgresql://dspacepg1:5432/researchworks56_db
>
> Migrating database to latest version... (Check dspace logs for details)
>
> Migration exception:
>
> java.sql.SQLException: Flyway migration error occurred
>
> at 
> org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:673)
>
> at 
> org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:576)
>
> at 
> org.dspace.storage.rdbms.DatabaseUtils.main(DatabaseUtils.java:221)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at 
> org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
>
> at 
> org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
>
> Caused by: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException:
>
> Migration V6.0_2015.03.07__DS-2701_Hibernate_migration.sql failed
>
> -
>
> SQL State  : 42P07
>
> Error Code : 0
>
> Message: ERROR: relation "dspaceobject" already exists
>
> Location   : 
> org/dspace/storage/rdbms/sqlmigration/postgres/V6.0_2015.03.07__DS-2701_Hibernate_migration.sql
>  
> (/var/dspace/file:/var/dspace/lib/dspace-api-6.3.jar!/org/dspace/storage/rdbms/sqlmigration/postgres/V6.0_2015.03.07__DS-2701_Hibernate_migration.sql)
>
> Line   : 14
>
> Statement  : CREATE TABLE dspaceobject
>
> (
>
> uuiduuid NOT NULL  PRIMARY KEY
>
> )
>


It seems that at least one table was created by the migration that failed 
-- that is, the migration succeeded *in part* but is listed as not yet 
executed.  Before doing anything else, I would dump the database as it is, 
so that you can get back into the current state if something goes wrong.

Then, if you have a dump of the database from before you began the upgrade, 
it might be safest to DROP the DATABASE, restore that dump, and start over.

If you have no pre-upgrade dump, then I would try DROPping the 
'dspaceobject' TABLE and running 'bin/dspace migrate' again.  Since I don't 
know the state of the database, this is dangerous advice -- there may be 
other damage that I don't see.

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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] How to merger two collections into one?

2019-01-24 Thread Alan Orth
Dear Stan,

If you log into DSpace web interface as an administrator and then navigate
to a collection you will see the "export metadata" link on the sidebar.
This will download a CSV file where one of the columns will be
"collection". You can change the collection there and re-upload it to
DSpace via the "import metadata" function on the web interface. The items
will move to the new collection.

You also have the option to "map" items from one collection to another.
When you do this the item stays in its "owning collection" and is simply
mapped to the other so it appears in both.

Regarding the links to the handles, they are persistent and will always
work for an item no matter where it is in the DSpace hierarchy of
communities and collections. Make sure to always use the real Handle links
when linking to these items in publications, social media, emails, etc
because they will always work even if you change the URL or domain name of
your repository: https://hdl.handle.net/10587/1915

See the batch metadata documentation here:
https://wiki.duraspace.org/display/DSDOC4x/Batch+Metadata+Editing

Regards,

On Thu, Jan 24, 2019 at 12:40 AM Stan Orlov  wrote:

> Greetings!
>
> We have two "Graduate Theses" collections.  The main one is in the "MSVU
> Theses" community at http://ec.msvu.ca/xmlui/handle/10587/95, but we also
> created long time ago another one in the "Department of Applied Human
> Nutrition" community at http://ec.msvu.ca/xmlui/handle/10587/548.  Is
> there a simple way for us to merge the two collections into one under the
> main "MSVU Theses" community?
>
> Ideally, it would be great if the existing external links to the applied
> human nutrition theses could still work after we move them to the main
> community.  We have "handle" in the URLs, so I wonder whether that is
> something that would need to be updated too?
>
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 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.
>


-- 
Alan Orth
alan.o...@gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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] Removing /xmlui from the URL

2019-01-24 Thread Alan Orth
Dear Stan,

Assuming you are using Tomcat, you need to rename your XMLUI web
application to "ROOT" and restart Tomcat. This is a special/reserved word
that makes Tomcat deploy the application at the root level. You will also
need to adjust your DSpace configuration, preferably in build.properties or
local.cfg for DSpace 5 and 6, respectively, and then rebuild, as this will
update all other configuration files as well.

As for handling the old links, you need to use Apache HTTPD's Redirect
command or mod_rewrite in your virtual host block to catch and redirect old
URLs. Redirect is simpler, but mod_rewrite will allow you to match regular
expressions so that's much more flexible. :)

Regards,

On Thu, Jan 24, 2019 at 12:07 AM Stan Orlov  wrote:

> Greetings!
>
> I followed the instructions to remove 8080 from our URL and I can now
> access our DSpace communities using either ec.msvu.ca:8080/xmlui or
> ec.msvu.ca/xmlui.  However, I would like for visitors to be able to
> access the main page of our DSpace by going to ec.msvu.ca (without
> "xmlui").  Ideally, it would be great if visitors with old links that have
> "/xmlui" in them could access the same page (for backward compatibility).
>
> I believe it is a simple matter of adding/removing something in
> server.xml, context.xml or dspace.cfg, but I can't come up with an answer.
>
>
> How can I achieve that?
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 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.
>


-- 
Alan Orth
alan.o...@gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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.