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
>> >>   
>>  
>> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java

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
> >>   
>  org.swordapp.server.ServiceDocumentAPI.get(Ser

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

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

[Tim Donohue]

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 
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="text">bwFDM test DSpace href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/1
> "> type="text">Faculty of Education xmlns="http://purl.org/net/sword/terms/";>true xmlns="http://purl.org/net/sword/terms/";>
> https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/1
>  href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/2
> "> type="text">Faculty of Science and Technology xmlns="http://purl.org/net/sword/terms/";>true xmlns="http://purl.org/net/sword/terms/";>
> https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/2
>  href="https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/12
> "> type="text">Oparu Bibliography xmlns="http://purl.org/net/sword/terms/";>true xmlns="http://purl.org/net/sword/terms/";>
> https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/12
>  xmlns="http://purl.org/dc/terms/";>for performance
> testing... xmlns="http://www.w3.org/2005/Atom";
> uri="http://www.dspace.org/ns/sword/2.0/";
> version="2.0">bwfdm.dspacet...@gmail.com xmlns="http://purl.org/net/sword/terms/";>2.0
>
> 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
> 
> '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
>
> 
> 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";>
>1.3
>true
>true
>-1
>http://www.dspace.org/ns/sword/1.3.1";
> version="1.3"/>
>
>   SARA DSpace 5 Test Instance
>
> 
>
> 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 <+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.
> 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.

[dspace-tech] SwordV2 spuriously delivers empty ServiceDocument

[Stefan Kombrink]

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";>bwFDM test DSpacehttps://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/1";>Faculty of Educationhttp://purl.org/net/sword/terms/";>truehttp://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/1https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/2";>Faculty of Science and Technologyhttp://purl.org/net/sword/terms/";>truehttp://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/2https://vm-152-118.bwcloud.uni-ulm.de/xmlui/handle/123456789/12";>Oparu Bibliographyhttp://purl.org/net/sword/terms/";>truehttp://purl.org/net/sword/terms/";>https://vm-152-118.bwcloud.uni-ulm.de/swordv2/servicedocument/123456789/12http://purl.org/dc/terms/";>for performance
testing...http://www.w3.org/2005/Atom";
uri="http://www.dspace.org/ns/sword/2.0/";
version="2.0">bwfdm.dspacet...@gmail.comhttp://purl.org/net/sword/terms/";>2.0

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


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";>
   1.3
   true
   true
   -1
   http://www.dspace.org/ns/sword/1.3.1";
version="1.3"/>
   
  SARA DSpace 5 Test Instance
   


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

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