[dspace-tech] Change in Operating System

[anjana . bunkar]

Currently our DSpace  is running on Centos Linux Operating System. Now we 
want to change our operating system .i.e. Ubuntu 18.04 for DSpace. Is it 
possible to take backup from Centos and restore in Ubuntu? 

-- 
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] streamlined upload with standalone app ?

[Andrea Schweer]

Hi Monika, all,

we've developed functionality similar to what you describe using Sword (v2
in our case) to allow students to deposit their thesis. You can see the
form here: https://researchcommons.waikato.ac.nz/deposit/ - in our case
this is a custom written (Spring Boot) web application that takes the
metadata + file(s), packages this up as a Sword submission package and
pushes it through to DSpace. A previous iteration of our form used PHP and
likewise pushed through to DSpace via Sword. Our current application uses
the official Sword 2 client for Java:
https://github.com/swordapp/JavaClient2.0

There is some more nuance to our Java application based on local
requirements (eg store a copy locally before pushing it through to DSpace
to isolate the submitter from system outages etc) but the capture +
package + push bit is really all you need to do; obviously you could put
the custom application behind your institutional login if you want to
auto-capture some metadata about the submitter etc.

cheers,
Andrea

On Thu, 29 Nov 2018 at 04:12, Monika Mevenkamp  wrote:

> We would love to set something up where researchers can upload a
> publication to a simple online form, where they fill in a couple fields,
> title, abstract, … and upload a file  then push submit. Ideally the form
> would push the data to a DSPACE instance’s workflow. Alternatively the data
> would be stored and a script would be able to grab it and transfer to
> designated DSPACE instance – aka a workflow.
>
>
>
> Does anybody know of an implementation of this or something similar ?
>
> We run DSpace 5 with the REST API.
>
>
>
> Monika
>
>
>
> --
>
> Monika Mevenkamp
>
> OIT Princeton University
>
> Phone: 609-258-4161
>
> Skype: mo-meven
>
>
>
>
>
> --
> 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.
>


-- 
Dr Andrea Schweer
Research Technologies Manager, ITS Programme & Commercial
The University of Waikato, Hamilton, New Zealand
+64-7-837 9120

-- 
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: OAI-PMH harvest from external system to DSpace collection

[Kiszely András]

Up.
Me and others are fighting with the same problem
Did u find any answer?

2018. március 29., csütörtök 11:42:57 UTC+2 időpontban Jakub Řihák a 
következőt írta:
>
> Hello everyone,
>
> I am trying to set a DSpace collection Content source to be a OAI-PMH set 
> from external system. I would like to harvest metadata of all items in the 
> external OAI-PMH set and use custom made crosswalk to "map" metadata from 
> external OAI set to metadata format defined in our DSpace instance.
>
> According to documentation for DSpace 5, there is the following  OAI 
> harvester configuration option in oai.cfg file:
>
> harvester.oai.metadataformats.PluginName
>
>  
>
>>  
>
>
>> This field can be repeated and serves as a link between the metadata 
>> formats supported by the local repository and those supported by the remote 
>> OAI-PMH provider. It follows the form 
>> harvester.oai.metadataformats.PluginName 
>> = NamespaceURI,Optional Display Name . The pluginName designates the 
>> metadata schemas that the harvester "knows" the local DSpace repository can 
>> support. Consequently, the PluginName must correspond to a previously 
>> declared ingestion crosswalk. The namespace value is used during 
>> negotiation with the remote OAI-PMH provider, matching it against a list 
>> returned by the ListMetadataFormats request, and resolving it to whatever 
>> metadataPrefix the remote provider has assigned to that namespace. Finally, 
>> the optional display name is the string that will be displayed to the user 
>> when setting up a collection for harvesting. If omitted, the 
>> PluginName:NamespaceURI combo will be displayed instead.
>
>
>
> There is the following advice: 
>
>>  Consequently, the PluginName must correspond to a previously declared 
>> ingestion crosswalk.
>
>
> I was trying to find how exactly i should declare new crosswalk, but found 
> nothing comprehensive so far. Does anyone have some experience with 
> defining a declaring new OAI ingest crosswalk?
>
> The idea behind this is to be able to "parse" as much information from 
> external OAI set as possible. When using standard Simple Dublin Core 
> Metadata Format (setting collection to have external content source in Edit 
> collection -> Content source  and then selecting Simple Dublin Core from 
> Metadata format list in setup form), we are only able to parse a very 
> limited amount of information from the external OAI-PMH set.
>
> I was trying to set up a new OAI metadata format (as described in OAI-PMH 
> dissemination) and reference this new OAI metadata format in oai.cfg, but 
> it didn't work. So far it seems hardly the same as OAI-PMH ingestion 
> metadata format, as I understand it.
>
> We are running DSpace 5.6 with XMLUI. 
>
> Thank you for any advice or suggestion,
> with best regards,
>
> Jakub Řihák
>
> Charles University, Central Library
>

-- 
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] SwordV2 spuriously delivers empty ServiceDocument

[Tim Donohue]

Hi Stefan,

Luckily, this PR is literally a one line change.

So, you could simply open up the [dspace-src]/dspace-swordv2/pom.xml file,
search for the "abdera-client", and then manually change the version from
1.1.1 to 1.1.3.

After doing so, you should do a full rebuild of DSpace... from
[dspace-src], run "mvn -U clean package", and then redeploy (e.g. "ant
update").

Does that make sense?

Tim

On Wed, Nov 28, 2018 at 11:29 AM Stefan Kombrink 
wrote:

> Hmm, I am using the official src release 5.10 and can't simply merge the
> PR.
> I found a
>
> ./dspace/modules/swordv2/target/war/work/org.swordapp/sword2-server/META-INF/maven/org.swordapp/sword2-server/pom.xml
> where I changes the abdera version to 1.1.3 but when I rebuilt the
> version is again 1.1.1 and the error will occur.
> Is there a way to force abdera version 1.1.3 using the official src
> tarball?
>
>
> On 11/28/18 5:47 PM, Stefan Kombrink wrote:
> > Thanks Tim,
> >
> >  that seems to be it! Going to test it and reporting back whether it
> > worked! Btw I am running DSpace 5.10
> >
> > greets
> > Stefan
> >
> > On 11/28/18 3:41 PM, Tim Donohue wrote:
> >> Hi Stefan,
> >>
> >> What specific version of DSpace are you testing with.  You mentioned
> >> DSpace 5, but didn't say which version.
> >>
> >> The error that you sent almost seems like a dependency conflict (or a
> >> missing dependency).  It reminded me of a similar error that someone
> >> else recently reported with SWORDv2 on DSpace v5.9 and v5.10
> specifically:
> >>
> >> https://jira.duraspace.org/browse/DS-4085
> >>
> >> That particular bug was caused by a dependency upgrade in v5.9 that
> >> seemed to conflict with the version of Apache Abdera we are using.
> >> There's a possible fix in the works in this Pull Request (which simply
> >> upgrades Apache Abdera to a compatible
> >> version): https://github.com/DSpace/DSpace/pull/2271
> >>
> >> The error stack you sent along also references "org.apache.abdera"
> >> (Apache Abdera), which makes me wonder if this is a similar error you
> >> are encountering.
> >>
> >> If you are running version 5.9 or 5.10, you might try upgrading Apache
> >> Abdera (i.e. applying the changes in that PR) to see if that fixes the
> >> bug.  If so, please do let us know -- as we are still reviewing/testing
> >> this change to ensure it works properly (and if so, it likely will be
> >> released in a future version of DSpace).
> >>
> >> - Tim
> >>
> >> On Wed, Nov 28, 2018 at 8:18 AM Stefan Kombrink
> >> mailto:stefan.kombr...@uni-ulm.de>> wrote:
> >>
> >> Okay, I've watched the wrong logs -here we go:
> >>
> >> tail -f /opt/tomcat/logs/localhost.2018-11-28.log
> >>
> >> SEVERE: Servlet.service() for servlet [servicedocument] in context
> with
> >> path [/swordv2] threw exception [Servlet execution threw an
> exception]
> >> with root cause java.lang.NoSuchMethodError:
> >>
>  
> org.apache.axiom.om.impl.llom.OMElementImpl.(Ljava/lang/String;Lorg/apache/axiom/om/OMNamespace;Lorg/apache/axiom/om/OMContainer;Lorg/apache/axiom/om/OMFactory;)V
> >> at
> org.apache.abdera.parser.stax.FOMElement.(FOMElement.java:88)
> >> at
> >>
>  
> org.apache.abdera.parser.stax.FOMExtensibleElement.(FOMExtensibleElement.java:52)
> >> at
> org.apache.abdera.parser.stax.FOMService.(FOMService.java:63)
> >> at
> >>
>  org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:113)
> >> at
> >>
>  org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:156)
> >> at org.apache.abdera.Abdera.newService(Abdera.java:110) at
> >> org.swordapp.server.ServiceDocument.(ServiceDocument.java:17)
> at
> >>
>  
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:101)
> >> at
> >>
>  
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:60)
> >> at
> >>
>  org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56)
> >> at
> >>
>  
> org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at
> >> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
> >>
>  
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> >> at
> >>
>  
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> >> at
> >>
>  org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> >> at
> >>
>  
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> >> at
> >>
>  
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> >> at
> >>
>  
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
> >> at
> >>
>  
> org.apache.catalina.core.StandardContextValve.invoke(Standard

Re: [dspace-tech] While uploading items in DSpace we are facing the below problem

[sumit lubal]

You should definitely include dspace.log snippet but just a general
solution could be checking if upload directory has correct permissions.
Remember that all dspace files should be owned by tomcat.

On Wed, Nov 28, 2018 at 9:16 AM Monika Mevenkamp  wrote:

>
>
> If you do not have an upload directory. You need to create one
>
> Did you check whether the directory exists ?
>
>
>
> --
>
> Monika Mevenkamp
>
> OIT Princeton University
>
> Phone: 609-258-4161
>
> Skype: mo-meven
>
>
>
>
> On Nov 27, 2018, at 10:58 PM, ANJANA BUNKAR <
> anjana.bun...@paruluniversity.ac.in> wrote:
>
> so, is there any solution of this problem?
>
>
>
> On Tue, Nov 27, 2018, 19:15 Monika Mevenkamp  wrote:
>
> The problem may be that you do not have a /dspace/upload directory
>
> The dspace user should be able o create files in that directory
>
>
>
> Monika
>
>
>
>
>
> --
>
> Monika Mevenkamp
>
> OIT Princeton University
>
> Phone: 609-258-4161
>
> Skype: mo-meven
>
>
>
>
>
> *From: *ANJANA BUNKAR 
> *Date: *Tuesday, November 27, 2018 at 1:02 AM
> *To: *"mome...@gmail.com" 
> *Subject: *Re: [dspace-tech] While uploading items in DSpace we are
> facing the below problem
>
>
>
> PFA of DSpace Error
>
> Ms. Anjana R. Bunkar
>
> Librarian
>
> Parul Inst. of Pharmacy & Research
>
> Faculty of Pharmacy
>
> Parul University
>
>
>
>
>
>
>
> On Tue, Nov 27, 2018 at 11:11 AM ANJANA BUNKAR <
> anjana.bun...@paruluniversity.ac.in> wrote:
>
> My problem is : I am facing a problem in Item Submission Process. In this
> process, when we uploading a file (File Form is PDF) and press the  Next
> Button,  instead of Review Step , the below message is showing:
>
>
>
> arul University 
> No such file or directory
>
> Login
> 
>
> · DSpace Home 
> No such file or directory
>
> Go to DSpace home 
>
> Please contact the site administrator if you wish to report this error. If
> possible, please provide details about what you were doing at the time this
> error occurred.
>
> Contact site administrator  || Show
> underlying error stack
> 
> Search DSpace
>
>
>
> DSpace software  copyright © 2002-2015  DuraSpace
> 
>
> Theme by
>
> Contact Us  | Send Feedback
> 
>
>
>
> Kindly do the needful.
>
>
> Ms. Anjana R. Bunkar
>
> Librarian
>
> Parul Inst. of Pharmacy & Research
>
> Faculty of Pharmacy
>
> Parul University
>
>
>
>
>
>
>
> On Mon, Nov 26, 2018 at 8:28 PM Monika Mevenkamp 
> wrote:
>
> Anjana
>
>
>
> This is not enough information to figure your problem out.
>
> Please reproduce the problem and resend with the section of your
> dspace.log file that shows the traces produced. Expect to find Exceptions.
> The file is usually at /dspace/log/dspace.log
>
>
>
> Monika
>
>
>
>
>
> --
>
> Monika Mevenkamp
>
> OIT Princeton University
>
> Phone: 609-258-4161
>
> Skype: mo-meven
>
>
>
>
>
> *From: * on behalf of "
> anjana.bun...@paruluniversity.ac.in" 
> *Date: *Monday, November 26, 2018 at 4:01 AM
> *To: *DSpace Technical Support 
> *Subject: *[dspace-tech] While uploading items in DSpace we are facing
> the below problem
>
>
> While uploading items in DSpace  we are facing the below problem  No
> such file or directory
>
> Go to DSpace home 
>
> Please contact the site administrator if you wish to report this error. If
> possible, please provide details about what you were doing at the time this
> error occurred.
>
> Contact site administrator  || Show
> underlying error stack
> 
>
> --
> 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.
>
> --
> 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 u

Re: [dspace-tech] SwordV2 spuriously delivers empty ServiceDocument

[Stefan Kombrink]

Hmm, I am using the official src release 5.10 and can't simply merge the PR.
I found a
./dspace/modules/swordv2/target/war/work/org.swordapp/sword2-server/META-INF/maven/org.swordapp/sword2-server/pom.xml
where I changes the abdera version to 1.1.3 but when I rebuilt the
version is again 1.1.1 and the error will occur.
Is there a way to force abdera version 1.1.3 using the official src tarball?


On 11/28/18 5:47 PM, Stefan Kombrink wrote:
> Thanks Tim,
> 
>  that seems to be it! Going to test it and reporting back whether it
> worked! Btw I am running DSpace 5.10
> 
> greets
> Stefan
> 
> On 11/28/18 3:41 PM, Tim Donohue wrote:
>> Hi Stefan,
>>
>> What specific version of DSpace are you testing with.  You mentioned
>> DSpace 5, but didn't say which version.
>>
>> The error that you sent almost seems like a dependency conflict (or a
>> missing dependency).  It reminded me of a similar error that someone
>> else recently reported with SWORDv2 on DSpace v5.9 and v5.10 specifically:
>>
>> https://jira.duraspace.org/browse/DS-4085
>>
>> That particular bug was caused by a dependency upgrade in v5.9 that
>> seemed to conflict with the version of Apache Abdera we are using.
>> There's a possible fix in the works in this Pull Request (which simply
>> upgrades Apache Abdera to a compatible
>> version): https://github.com/DSpace/DSpace/pull/2271
>>
>> The error stack you sent along also references "org.apache.abdera"
>> (Apache Abdera), which makes me wonder if this is a similar error you
>> are encountering.  
>>
>> If you are running version 5.9 or 5.10, you might try upgrading Apache
>> Abdera (i.e. applying the changes in that PR) to see if that fixes the
>> bug.  If so, please do let us know -- as we are still reviewing/testing
>> this change to ensure it works properly (and if so, it likely will be
>> released in a future version of DSpace).
>>
>> - Tim
>>
>> On Wed, Nov 28, 2018 at 8:18 AM Stefan Kombrink
>> mailto:stefan.kombr...@uni-ulm.de>> wrote:
>>
>> Okay, I've watched the wrong logs -here we go:
>>
>> tail -f /opt/tomcat/logs/localhost.2018-11-28.log
>>
>> SEVERE: Servlet.service() for servlet [servicedocument] in context with
>> path [/swordv2] threw exception [Servlet execution threw an exception]
>> with root cause java.lang.NoSuchMethodError:
>> 
>> org.apache.axiom.om.impl.llom.OMElementImpl.(Ljava/lang/String;Lorg/apache/axiom/om/OMNamespace;Lorg/apache/axiom/om/OMContainer;Lorg/apache/axiom/om/OMFactory;)V
>> at org.apache.abdera.parser.stax.FOMElement.(FOMElement.java:88)
>> at
>> 
>> org.apache.abdera.parser.stax.FOMExtensibleElement.(FOMExtensibleElement.java:52)
>> at org.apache.abdera.parser.stax.FOMService.(FOMService.java:63)
>> at
>> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:113)
>> at
>> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:156)
>> at org.apache.abdera.Abdera.newService(Abdera.java:110) at
>> org.swordapp.server.ServiceDocument.(ServiceDocument.java:17) at
>> 
>> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:101)
>> at
>> 
>> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:60)
>> at
>> org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56)
>> at
>> 
>> org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
>> 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>> at
>> 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>> at
>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>> at
>> 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>> at
>> 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>> at
>> 
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
>> at
>> 
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
>> at
>> 
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
>> at
>> 
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
>> at
>> 
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
>> at
>> 
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>> at
>> 
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
>>  

Re: [dspace-tech] SwordV2 spuriously delivers empty ServiceDocument

[Stefan Kombrink]

Thanks Tim,

 that seems to be it! Going to test it and reporting back whether it
worked! Btw I am running DSpace 5.10

greets
Stefan

On 11/28/18 3:41 PM, Tim Donohue wrote:
> Hi Stefan,
> 
> What specific version of DSpace are you testing with.  You mentioned
> DSpace 5, but didn't say which version.
> 
> The error that you sent almost seems like a dependency conflict (or a
> missing dependency).  It reminded me of a similar error that someone
> else recently reported with SWORDv2 on DSpace v5.9 and v5.10 specifically:
> 
> https://jira.duraspace.org/browse/DS-4085
> 
> That particular bug was caused by a dependency upgrade in v5.9 that
> seemed to conflict with the version of Apache Abdera we are using.
> There's a possible fix in the works in this Pull Request (which simply
> upgrades Apache Abdera to a compatible
> version): https://github.com/DSpace/DSpace/pull/2271
> 
> The error stack you sent along also references "org.apache.abdera"
> (Apache Abdera), which makes me wonder if this is a similar error you
> are encountering.  
> 
> If you are running version 5.9 or 5.10, you might try upgrading Apache
> Abdera (i.e. applying the changes in that PR) to see if that fixes the
> bug.  If so, please do let us know -- as we are still reviewing/testing
> this change to ensure it works properly (and if so, it likely will be
> released in a future version of DSpace).
> 
> - Tim
> 
> On Wed, Nov 28, 2018 at 8:18 AM Stefan Kombrink
> mailto:stefan.kombr...@uni-ulm.de>> wrote:
> 
> Okay, I've watched the wrong logs -here we go:
> 
> tail -f /opt/tomcat/logs/localhost.2018-11-28.log
> 
> SEVERE: Servlet.service() for servlet [servicedocument] in context with
> path [/swordv2] threw exception [Servlet execution threw an exception]
> with root cause java.lang.NoSuchMethodError:
> 
> org.apache.axiom.om.impl.llom.OMElementImpl.(Ljava/lang/String;Lorg/apache/axiom/om/OMNamespace;Lorg/apache/axiom/om/OMContainer;Lorg/apache/axiom/om/OMFactory;)V
> at org.apache.abdera.parser.stax.FOMElement.(FOMElement.java:88)
> at
> 
> org.apache.abdera.parser.stax.FOMExtensibleElement.(FOMExtensibleElement.java:52)
> at org.apache.abdera.parser.stax.FOMService.(FOMService.java:63)
> at
> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:113)
> at
> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:156)
> at org.apache.abdera.Abdera.newService(Abdera.java:110) at
> org.swordapp.server.ServiceDocument.(ServiceDocument.java:17) at
> 
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:101)
> at
> 
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:60)
> at
> org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56)
> at
> 
> org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
> 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
> at
> 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
> at
> 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
> at
> 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
> at
> 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
> at
> 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
> at
> 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
> at
> 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
> at
> org.apache.tomcat.util.net
> 
> .JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
> 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java

Re: [dspace-tech] could not update messages.properties

[Tim Donohue]

Hello,

Those instructions you linked to are correct.  So, placing the
"messages.properties" file in your
[dspace-src]/dspace/modules/jspui/src/main/resources/ path should work fine
(and this directory doesn't exist by default).

You could always check to be sure the final "dspace-api.jar" contains your
updated messages.properties file (you can unzip a JAR file just like a
normal ZIP).  As long as it is updated in that file, then everything should
work.

The only oddity that I notice in your details is that you seem to have a
strange directory structure.  Is your "dspace-source" folder really at
"C:\dspace-6.3-src-release\dspace-6.3-src-release\" (with
"dspace-6.3-src-release" repeated twice)?

Unfortunately, that's all the advice I can give based on the information
you've provided.  Maybe someone else on this list will have ideas of what
could have gone wrong in your process.

- Tim


On Thu, Nov 22, 2018 at 11:45 PM Ze Victor Harry 
wrote:

> hi guys i wanted to update the contents of  messages.properties and i
> followed instructions on this page
> https://wiki.duraspace.org/display/DSDOC6x/Localization+L10n the
> C:\dspace-6.3-src-release\dspace-6.3-src-release\dspace\modules\jspui\src\main\resources
> path was not avalable so i created the path and copied messages.properties
> from
> C:\dspace-6.3-src-release\dspace-6.3-src-release\dspace-api\src\main\resources
> to it.but after rebuilding dspace using mvn package from
> [dspace-source]/dspace/directory and restarting tomcat nothing changes.
> can some one tell me what am i doing wrong?
>
> --
> 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.
>
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

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

[Tim Donohue]

Hello,

While you can import an Embargo via metadata, the actual embargo itself is
set on Resource Policies (access controls) in DSpace.  So, that's where
you'd want to modify the lift date. See the documentation at:
https://wiki.duraspace.org/display/DSDOC6x/Embargo#Embargo-DSpaceEmbargoFunctionality

If you are trying to modify the lift date of an Item that is already in the
system, see the recommendations at:
https://wiki.duraspace.org/display/DSDOC6x/Embargo#Embargo-ManagingEmbargoesonexistingItems

If you are looking to add embargo information during the Submission process
itself, we have two different out-of-the-box Submission steps that can be
enabled to capture Embargo information.  See the documentation at:
https://wiki.duraspace.org/display/DSDOC6x/Embargo#Embargo-SubmissionProcess


If you have more questions on embargo, let us know on this list.

Thanks,

Tim

On Tue, Nov 20, 2018 at 5:11 AM Kiriaki Roditi 
wrote:

> Hello everyone,
>
>
>
> I am trying to configure Embargo via metadata terms and set the embargo
> liftDate to 3 years after the item was installed in the Repository.
>
> I have configured the appropriate metadata field and created a list of
> metadata values in input-forms.xml but I cannot set the date I need in the
> liftDate metadata field.
>
> Is there a way to achieve that in DSpace 6.3 (Mirage2 interface)?
>
>
>
> Thank you in advance.
>
>
>
> Best regards,
>
> Kiriaki
>
>
>
>
>
> --
> 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.
>
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

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

[Michael Plate]

Hi Monika,

Am 28.11.18 um 16:12 schrieb Monika Mevenkamp:
We would love to set something up where researchers can upload a 
publication to a simple online form, where they fill in a couple fields, 
title, abstract, … and upload a file  then push submit. Ideally the form 
would push the data to a DSPACE instance’s workflow. Alternatively the 
data would be stored and a script would be able to grab it and transfer 
to designated DSPACE instance – aka a workflow.


Does anybody know of an implementation of this or something similar ?

[…]

when setting up our new DSpace (5.10) I thought about this, too.
But due to lack of time..
We once had the possibility to upload via SWORD by a different system, 
but only three persons ever used it in a couple of years.


So SWORD may be a solution.


Michael


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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [dspace-tech] While uploading items in DSpace we are facing the below problem

[Monika Mevenkamp]

If you do not have an upload directory. You need to create one
Did you check whether the directory exists ?

--
Monika Mevenkamp
OIT Princeton University
Phone: 609-258-4161
Skype: mo-meven


On Nov 27, 2018, at 10:58 PM, ANJANA BUNKAR 
mailto:anjana.bun...@paruluniversity.ac.in>>
 wrote:
so, is there any solution of this problem?

On Tue, Nov 27, 2018, 19:15 Monika Mevenkamp 
mailto:mome...@gmail.com>> wrote:
The problem may be that you do not have a /dspace/upload directory
The dspace user should be able o create files in that directory

Monika


--
Monika Mevenkamp
OIT Princeton University
Phone: 609-258-4161
Skype: mo-meven


From: ANJANA BUNKAR 
mailto:anjana.bun...@paruluniversity.ac.in>>
Date: Tuesday, November 27, 2018 at 1:02 AM
To: "mome...@gmail.com" 
mailto:mome...@gmail.com>>
Subject: Re: [dspace-tech] While uploading items in DSpace we are facing the 
below problem

PFA of DSpace Error
Ms. Anjana R. Bunkar
Librarian
Parul Inst. of Pharmacy & Research
Faculty of Pharmacy
Parul University



On Tue, Nov 27, 2018 at 11:11 AM ANJANA BUNKAR 
mailto:anjana.bun...@paruluniversity.ac.in>>
 wrote:
My problem is : I am facing a problem in Item Submission Process. In this 
process, when we uploading a file (File Form is PDF) and press the  Next 
Button,  instead of Review Step , the below message is showing:

arul University
No such file or directory

Login

* DSpace Home

No such file or directory

Go to DSpace home

Please contact the site administrator if you wish to report this error. If 
possible, please provide details about what you were doing at the time this 
error occurred.

Contact site administrator || Show 
underlying error 
stack

Search DSpace

DSpace software copyright © 2002-2015  
DuraSpace
Theme by   
Contact Us | Send 
Feedback

Kindly do the needful.

Ms. Anjana R. Bunkar
Librarian
Parul Inst. of Pharmacy & Research
Faculty of Pharmacy
Parul University



On Mon, Nov 26, 2018 at 8:28 PM Monika Mevenkamp 
mailto:mome...@gmail.com>> wrote:
Anjana

This is not enough information to figure your problem out.
Please reproduce the problem and resend with the section of your dspace.log 
file that shows the traces produced. Expect to find Exceptions. The file is 
usually at /dspace/log/dspace.log

Monika


--
Monika Mevenkamp
OIT Princeton University
Phone: 609-258-4161
Skype: mo-meven


From: mailto:dspace-tech@googlegroups.com>> on 
behalf of 
"anjana.bun...@paruluniversity.ac.in"
 
mailto:anjana.bun...@paruluniversity.ac.in>>
Date: Monday, November 26, 2018 at 4:01 AM
To: DSpace Technical Support 
mailto:dspace-tech@googlegroups.com>>
Subject: [dspace-tech] While uploading items in DSpace we are facing the below 
problem

While uploading items in DSpace  we are facing the below problem




No such file or directory

Go to DSpace home

Please contact the site administrator if you wish to report this error. If 
possible, please provide details about what you were doing at the time this 
error occurred.

Contact site administrator || Show 
underlying error 
stack
--
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.

-- 
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/d

[dspace-tech] streamlined upload with standalone app ?

[Monika Mevenkamp]

We would love to set something up where researchers can upload a publication to 
a simple online form, where they fill in a couple fields, title, abstract, … 
and upload a file  then push submit. Ideally the form would push the data to a 
DSPACE instance’s workflow. Alternatively the data would be stored and a script 
would be able to grab it and transfer to designated DSPACE instance – aka a 
workflow.

Does anybody know of an implementation of this or something similar ?
We run DSpace 5 with the REST API.

Monika

--
Monika Mevenkamp
OIT Princeton University
Phone: 609-258-4161
Skype: mo-meven


-- 
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] SwordV2 spuriously delivers empty ServiceDocument

[Tim Donohue]

Hi Stefan,

What specific version of DSpace are you testing with.  You mentioned DSpace
5, but didn't say which version.

The error that you sent almost seems like a dependency conflict (or a
missing dependency).  It reminded me of a similar error that someone else
recently reported with SWORDv2 on DSpace v5.9 and v5.10 specifically:

https://jira.duraspace.org/browse/DS-4085

That particular bug was caused by a dependency upgrade in v5.9 that seemed
to conflict with the version of Apache Abdera we are using. There's a
possible fix in the works in this Pull Request (which simply upgrades
Apache Abdera to a compatible version):
https://github.com/DSpace/DSpace/pull/2271

The error stack you sent along also references "org.apache.abdera" (Apache
Abdera), which makes me wonder if this is a similar error you are
encountering.

If you are running version 5.9 or 5.10, you might try upgrading Apache
Abdera (i.e. applying the changes in that PR) to see if that fixes the
bug.  If so, please do let us know -- as we are still reviewing/testing
this change to ensure it works properly (and if so, it likely will be
released in a future version of DSpace).

- Tim

On Wed, Nov 28, 2018 at 8:18 AM Stefan Kombrink 
wrote:

> Okay, I've watched the wrong logs -here we go:
>
> tail -f /opt/tomcat/logs/localhost.2018-11-28.log
>
> SEVERE: Servlet.service() for servlet [servicedocument] in context with
> path [/swordv2] threw exception [Servlet execution threw an exception]
> with root cause java.lang.NoSuchMethodError:
>
> org.apache.axiom.om.impl.llom.OMElementImpl.(Ljava/lang/String;Lorg/apache/axiom/om/OMNamespace;Lorg/apache/axiom/om/OMContainer;Lorg/apache/axiom/om/OMFactory;)V
> at org.apache.abdera.parser.stax.FOMElement.(FOMElement.java:88)
> at
>
> org.apache.abdera.parser.stax.FOMExtensibleElement.(FOMExtensibleElement.java:52)
> at org.apache.abdera.parser.stax.FOMService.(FOMService.java:63)
> at
> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:113)
> at
> org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:156)
> at org.apache.abdera.Abdera.newService(Abdera.java:110) at
> org.swordapp.server.ServiceDocument.(ServiceDocument.java:17) at
>
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:101)
> at
>
> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:60)
> at
> org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56)
> at
>
> org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
> at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
> at
>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
> at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
> at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
> at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
> at
>
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
> at
>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
> at
> org.apache.tomcat.util.net
> .JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
>
> java -version
> java version "1.7.0_95"
> OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-3)
> OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
>
> I've purged java 1.8 and JDK8 which had been installed as well, ran
> mvn clean package and made an
> ant fresh install
>
> But to no avail...
>
> How can this happen?
>
> regards Stefan
>
>
> On 11/28/18 10:09 AM, Stefan Kombrink wrote:
> > Thanks Tim,
> >
> >  you will f

Re: [dspace-tech] SwordV2 spuriously delivers empty ServiceDocument

[Stefan Kombrink]

Okay, I've watched the wrong logs -here we go:

tail -f /opt/tomcat/logs/localhost.2018-11-28.log

SEVERE: Servlet.service() for servlet [servicedocument] in context with
path [/swordv2] threw exception [Servlet execution threw an exception]
with root cause java.lang.NoSuchMethodError:
org.apache.axiom.om.impl.llom.OMElementImpl.(Ljava/lang/String;Lorg/apache/axiom/om/OMNamespace;Lorg/apache/axiom/om/OMContainer;Lorg/apache/axiom/om/OMFactory;)V
at org.apache.abdera.parser.stax.FOMElement.(FOMElement.java:88)
at
org.apache.abdera.parser.stax.FOMExtensibleElement.(FOMExtensibleElement.java:52)
at org.apache.abdera.parser.stax.FOMService.(FOMService.java:63)
at
org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:113)
at
org.apache.abdera.parser.stax.FOMFactory.newService(FOMFactory.java:156)
at org.apache.abdera.Abdera.newService(Abdera.java:110) at
org.swordapp.server.ServiceDocument.(ServiceDocument.java:17) at
org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:101)
at
org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:60)
at
org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56)
at
org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)


java -version
java version "1.7.0_95"
OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-3)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

I've purged java 1.8 and JDK8 which had been installed as well, ran
mvn clean package and made an
ant fresh install

But to no avail...

How can this happen?

regards Stefan


On 11/28/18 10:09 AM, Stefan Kombrink wrote:
> Thanks Tim,
> 
>  you will find the log excerpts attached (DEBUG enabled for DSpace).
> The mentioned requests were around 1:28PM
> 
> regards Stefan
> 
> On 11/26/18 4:52 PM, Tim Deonohue wrote:
>> Hi Stefan,
>>
>> I'd recommend checking your log files closely (both DSpace and Tomcat)
>> when the error occurs.  My suspicion is there may be an error reported
>> there that could help diagnose the problem.  Let us know on this list
>> what you find.
>>
>> Tim
>>
>> On Mon, Nov 26, 2018 at 7:49 AM Stefan Kombrink
>> mailto:stefan.kombr...@uni-ulm.de>> wrote:
>>
>> Hi there,
>>
>>  we are struggling for a long time already with this issue that under
>> unidentified circumstances our DSpace Instances stop delivering service
>> documents via SwordV2.
>>
>> I do multiple setups where I follow identical installation instructions
>> line by line, and yet I am able to obtain this behavior on one machine
>> and not on another. However, the issue is not deliberately reproducible.
>> Basically we have no idea when it happens nor what may be the cause.
>>
>> Here it can be observed:
>>
>> Working machine:
>>
>> curl -i https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument
>> --user
>>  
>> 'katako...@gmail.com:iamthebest'
>>
>> http://www.w3.org/2007/app";
>> xmlns:atom="http://www.w3.org/2005/Atom";>> type="te

[dspace-tech] Re: Problem in Item Submission

[Mark H. Wood]

On Tuesday, November 27, 2018 at 11:05:02 PM UTC-5, 
anjana.bun...@paruluniversity.ac.in wrote:
>
> My problem is : I am facing a problem in Item Submission Process. In this 
> process, when we uploading a file (File Form is PDF) and press the  Next 
> Button,  instead of Review Step , the below message is showing:
>
> *No such file or directory*
>
> Go to DSpace home 
>
> Please contact the site administrator if you wish to report this error. If 
> possible, please provide details about what you were doing at the time this 
> error occurred.
>
> Contact site administrator  || 
> Show 
> underlying error stack 
> 
>
>  
>
> *Java stacktrace: *
>
> java.io.IOException: No such file or directory
>
> at java.io.UnixFileSystem.createFileExclusively(Native Method)
>
> at java.io.File.createNewFile(File.java:1012)
>
> at 
> edu.sdsc.grid.io.local.LocalFile.createNewFile(LocalFile.java:486)
>
> at 
> org.dspace.storage.bitstore.BitstreamStorageManager.store(BitstreamStorageManager.java:300)
>


It seems that DSpace is failing when it tries to create a file in the 
assetstore.  I would first check that the configured value of 
'assetstore.dir' (in config/dspace.cfg, or for DSpace 6 perhaps 
config/local.cfg) is correct and points to an existing directory that 
Tomcat's account is allowed to write.

-- 
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] Dspace with CMIS

[Mark H. Wood]

I thought I had seen CMIS mentioned once before -- it feels like the second 
time I have thought, "this can't possibly be about the OSI Common 
Management Information Service, so what is this CMIS?"  The only such 
reference I could find was a GSOC proposal from 2010.  I can't point to any 
other previous interest in CMIS, but that doesn't mean it is a poor idea.

How would DSpace participate in CMIS exchanges?  Client? server? both?  
What would it allow DSpace to do that it can't do now?  Is that aligned 
with how DSpace is positioned in the repository community?  Who is 
interested in doing the necessary work?

I see that ASF has a CMIS implementation:  Apache Chemistry.  If someone 
wants to work on adding CMIS to DSpace, that might be a sensible starting 
point.

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