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 > <stefan.kombr...@uni-ulm.de <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.<init>(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.<init>(FOMElement.java:88) > at > > org.apache.abdera.parser.stax.FOMExtensibleElement.<init>(FOMExtensibleElement.java:52) > at org.apache.abdera.parser.stax.FOMService.<init>(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.<init>(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 > > <http://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 > >> <stefan.kombr...@uni-ulm.de <mailto:stefan.kombr...@uni-ulm.de> > <mailto:stefan.kombr...@uni-ulm.de > <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 > >> > <https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument--user> > 'katako...@gmail.com:iamthebest' > >> > >> <service xmlns="http://www.w3.org/2007/app"; > >> xmlns:atom="http://www.w3.org/2005/Atom";><workspace><atom:title > >> type="text">bwFDM test DSpace</atom:title><collection > >> > > href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/1";><atom:title > >> type="text">Faculty of Education</atom:title><mediation > >> xmlns="http://purl.org/net/sword/terms/";>true</mediation><service > >> > > xmlns="http://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/1</service></collection><collection > >> > > href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/2";><atom:title > >> type="text">Faculty of Science and > Technology</atom:title><mediation > >> xmlns="http://purl.org/net/sword/terms/";>true</mediation><service > >> > > xmlns="http://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/2</service></collection><collection > >> > > href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/12";><atom:title > >> type="text">Oparu Bibliography</atom:title><mediation > >> xmlns="http://purl.org/net/sword/terms/";>true</mediation><service > >> > > xmlns="http://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/12</service><abstract > >> xmlns="http://purl.org/dc/terms/";>for performance > >> testing...</abstract></collection></workspace><generator > >> xmlns="http://www.w3.org/2005/Atom"; > >> uri="http://www.dspace.org/ns/sword/2.0/"; > >> version="2.0">bwfdm.dspacet...@gmail.com > <mailto:bwfdm.dspacet...@gmail.com> > >> <mailto:bwfdm.dspacet...@gmail.com > <mailto:bwfdm.dspacet...@gmail.com>></generator><version > >> xmlns="http://purl.org/net/sword/terms/";>2.0</version></service> > >> > >> Non-Working machine: > >> > >> curl -i > >> > http://dspace5-test.sara-service.org:8080/swordv2/servicedocument > --user > >> 'katako...@gmail.com:iamthebest' > >> > >> HTTP/1.1 200 OK > >> Server: Apache-Coyote/1.1 > >> Transfer-Encoding: chunked > >> Date: Mon, 26 Nov 2018 13:42:41 GMT > >> > >> curl: (18) transfer closed with outstanding read data remaining > >> > >> What is strange is that I can obtain a sword service document > whereas I > >> can't on the okay-working machine: > >> > >> curl -i > http://dspace5-test.sara-service.org:8080/sword/servicedocument > >> --user > >> > <http://dspace5-test.sara-service.org:8080/sword/servicedocument--user> > >> 'katako...@gmail.com:iamthebest' > >> > >> HTTP/1.1 200 OK > >> Server: Apache-Coyote/1.1 > >> Content-Type: application/atomsvc+xml;charset=UTF-8 > >> Transfer-Encoding: chunked > >> Date: Mon, 26 Nov 2018 13:44:11 GMT > >> > >> <?xml version="1.0" encoding="UTF-8"?> > >> <app:service xmlns:app="http://www.w3.org/2007/app"; > >> xmlns:sword="http://purl.org/net/sword/"; > >> xmlns:dcterms="http://purl.org/dc/terms/"; > >> xmlns:atom="http://www.w3.org/2005/Atom";> > >> <sword:version>1.3</sword:version> > >> <sword:verbose>true</sword:verbose> > >> <sword:noOp>true</sword:noOp> > >> <sword:maxUploadSize>-1</sword:maxUploadSize> > >> <atom:generator uri="http://www.dspace.org/ns/sword/1.3.1"; > >> version="1.3"/> > >> <app:workspace> > >> <atom:title type="text">SARA DSpace 5 Test > Instance</atom:title> > >> </app:workspace> > >> </app:service> > >> > >> We find this an issue for both DSpace5 and DSpace6, in > DSpace5 however > >> it seems to happen much more frequently. > >> > >> Clues & suggestions are highly welcome! > >> > >> With best regards > >> Stefan > >> > >> -- > >> Stefan Kombrink > >> Universität Ulm > >> Kommunikations- und Informationszentrum (kiz) > >> Abteilung Informationsmedien > >> +49-731-50-31482 <tel:+49%20731%205031482> > <tel:+49%20731%205031482> > >> > >> -- > >> 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 > <mailto:dspace-tech%2bunsubscr...@googlegroups.com> > >> <mailto:dspace-tech%2bunsubscr...@googlegroups.com > <mailto:dspace-tech%252bunsubscr...@googlegroups.com>>. > >> To post to this group, send email to > dspace-tech@googlegroups.com <mailto:dspace-tech@googlegroups.com> > >> <mailto:dspace-tech@googlegroups.com > <mailto: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 > > > > -- > Stefan Kombrink > Universität Ulm > Kommunikations- und Informationszentrum (kiz) > Abteilung Informationsmedien > +49-731-50-31482 <tel:+49%20731%205031482> > > -- > 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 > <mailto:dspace-tech%2bunsubscr...@googlegroups.com>. > To post to this group, send email to dspace-tech@googlegroups.com > <mailto: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 -- Stefan Kombrink Universität Ulm Kommunikations- und Informationszentrum (kiz) Abteilung Informationsmedien +49-731-50-31482 -- 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.
