Re: [dspace-tech] Change in Operating System

[Tim Donohue]

Hello Anjana,

Yes, it should be possible to copy DSpace itself from a Centos Linux system
to an Ubuntu system.  DSpace will work on any Operating System.

However, you should be very careful to look at any changes in the software
DSpace requires as prerequisites (Java, Maven, Ant, Database, Tomcat).

So, for example, if the version of PostgreSQL (or Oracle) database changes,
you may need to export from the old database and reimport into the new one
(using database tools like "pg_dump" for Postgres).  Additionally, if you
are using a different version of Maven, Java or Ant, you may need to
completely recompile DSpace (mvn package) and redeploy it (ant update) on
the new system.  Finally, if you are using a different version of Tomcat
(or similar), you may need to check that any previous Tomcat configurations
will work on the new version (look at the Tomcat upgrade notes).

So, this sort of OS change should be fine.  I'd recommend doing it on a
test/demo server first though, to ensure it all goes smoothly.  Then you'll
know what to look out for when you do it in Production.

Tim

On Wed, Nov 28, 2018 at 10:35 PM 
wrote:

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

[Monika Mevenkamp]

We’d want to allow everybody who can get through to the form (firewalls, 
authentication/CAS)  to be able to submit – the form would then be trusted to 
upload to collections we tell it about.  Plus we’d be able to set the form up 
with help text and what not as we like.

We do not want autocreation of accounts on our repository instance.

Monika

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


From:  on behalf of "Mark H. Wood" 

Date: Thursday, November 29, 2018 at 9:58 AM
To: DSpace Technical Support 
Subject: [dspace-tech] Re: streamlined upload with standalone app ?

I'm curious:  how would this differ from slashing all of the non-required 
fields and panels out of the DSpace input forms and just submitting to DSpace 
directly?
--
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/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: streamlined upload with standalone app ?

[Mark H. Wood]

I'm curious:  how would this differ from slashing all of the non-required 
fields and panels out of the DSpace input forms and just submitting to 
DSpace directly?

-- 
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: Problem in Item Submission

[Kiszely András]

Hi, same problem, but i have a not fresh installed dspace 6.3.
I'm sure that config is OK, i did submit before and nothing has been 
changed since.

:O

Regards
A.

2018. november 28., szerda 5:05:02 UTC+1 időpontban 
anjana...@paruluniversity.ac.in a következőt írta:
>
> 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)
>
> at org.dspace.content.Bitstream.create(Bitstream.java:204)
>
> at org.dspace.content.Bundle.createBitstream(Bundle.java:384)
>
> at org.dspace.content.Item.createSingleBitstream(Item.java:895)
>
> at 
> org.dspace.submit.step.UploadStep.processUploadFile(UploadStep.java:502)
>
> at 
> org.dspace.submit.step.UploadStep.doProcessing(UploadStep.java:145)
>
> at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown 
> Source)
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:497)
>
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155)
>
> at 
> org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
>
> at 
> org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3237)
>
> at 
> org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394)
>
> at 
> org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:162)
>
> at 
> org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393)
>
> at 
> org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834)
>
> at 
> org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:160)
>
> at org.mozilla.javascript.Context.call(Context.java:538)
>
> at 
> org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1833)
>
> at 
> org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1803)
>
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:698)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:94)
>
> at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
>
> at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:82)
>
> at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
>
> at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81)
>
> at 
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239)
>
> at 
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.buildPipeline(ConcreteTreeProcessor.java:186)
>
> at 
> org.apache.cocoon.components.treeprocessor.TreeProcessor.buildPipeline(TreeProcessor.java:260)
>
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:107)
>
> at 
> 

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

[Stefan Kombrink]

Oh never mind, I've utilized the wrong tarball! :D

On 11/29/18 10:19 AM, Stefan Kombrink wrote:
> Hi Tim,
> 
>  that's how I did it :) However, the release tar ball does not contain
> the modules sources, thats why I needed to check out from git directly
> and apply the fix. My question was regarding how to apply this fix in
> the release tarballs where the files do not exist.
> 
> I acknowledge this solved the issue and will add a comment to the PR.
> Is there a plan when the next version (5.11?) with this fix will be
> released?
> 
> thx & greetings
> Stefan
> 
> On 11/28/18 7:07 PM, Tim Donohue wrote:
>> 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
>> mailto:stefan.kombr...@uni-ulm.de>> 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
>> >>   
>>  
>> 

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

[Stefan Kombrink]

Hi Tim,

 that's how I did it :) However, the release tar ball does not contain
the modules sources, thats why I needed to check out from git directly
and apply the fix. My question was regarding how to apply this fix in
the release tarballs where the files do not exist.

I acknowledge this solved the issue and will add a comment to the PR.
Is there a plan when the next version (5.11?) with this fix will be
released?

thx & greetings
Stefan

On 11/28/18 7:07 PM, Tim Donohue wrote:
> 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
> mailto:stefan.kombr...@uni-ulm.de>> 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
> >>   
>