You can subscribe to this list here.
2008 |
Jan
(22) |
Feb
(8) |
Mar
(9) |
Apr
(4) |
May
(17) |
Jun
(29) |
Jul
(11) |
Aug
(13) |
Sep
(17) |
Oct
(14) |
Nov
(41) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(17) |
Feb
(26) |
Mar
(18) |
Apr
(1) |
May
(11) |
Jun
(20) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2010 |
Jan
(23) |
Feb
(7) |
Mar
(9) |
Apr
(13) |
May
(5) |
Jun
|
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2011 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(14) |
Jul
(22) |
Aug
(1) |
Sep
(2) |
Oct
(11) |
Nov
(11) |
Dec
(35) |
2012 |
Jan
(17) |
Feb
(12) |
Mar
(41) |
Apr
(40) |
May
(41) |
Jun
(27) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
|
Dec
(11) |
2013 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(1) |
Jun
(18) |
Jul
(10) |
Aug
(16) |
Sep
(2) |
Oct
(1) |
Nov
(14) |
Dec
(11) |
2014 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
|
May
(8) |
Jun
(1) |
Jul
(7) |
Aug
(10) |
Sep
(8) |
Oct
(8) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Edwin S. <edw...@yo...> - 2013-07-10 21:52:40
|
Philip, If this is related to, ahem, multipart-related support, that simply didn't work in swordapp (at least last year). It was one of the issues I addressed in my fork, see: https://github.com/mediashelf/sword2-server/commit/5458968f7d4e73c76bd35c18f6d4102d99663db3 https://github.com/mediashelf/sword2-server/commit/1f6c677c36b409cb929370df31d28e162cf56632 -Eddie On Jul 10, 2013, at 5:05 PM, Philip Durbin <phi...@ha...> wrote: > I'm still using sword2-server-1.0-classes.jar and got a strange > exception today when trying to make deposit.isMultipart() true with > the proper arguments to curl. > > I'm able to reproduce the exception in my Vagrant environment so I > just added this issue: > > MalformedStreamException with Content-Type: multipart/related · Issue > #2 · dvn/swordpoc - https://github.com/dvn/swordpoc/issues/2 > > Anyway, I'm still investigating this but I thought I'd bring it up > while it's on my mind. > > Before working on this too hard I'll probably return to cases where > deposit.isBinaryOnly() or deposit.isEntryOnly() is true... seems like > I'll want to get multipart working eventually though... > > Phil > > p.s. Here's what I wrote in that issue #2: > > While looking at isMultipart() in > https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/Deposit.java > I attempted to use curl to upload multipart.dat from > https://github.com/swordapp/Simple-Sword-Server/blob/master/tests/resources/multipart.dat > with these commands... > > wget https://raw.github.com/swordapp/Simple-Sword-Server/master/tests/resources/multipart.dat > curl --insecure --data-binary "@multipart.dat" -H 'Content-Type: > multipart/related; boundary="===============0670350989=="' -H > "MIME-Version: 1.0" > https://sword:sword@localhost:8181/swordpoc/collection/a4f21cdc-f20c-4c82-b63e-5df81f809417 > > ... and got this exception: > > [#|2013-07-10T21:39:34.677+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-2;|StandardWrapperValve[collection]: > PWC1406: Servlet.service() for servlet collection threw exception > org.apache.commons.fileupload.MultipartStream$MalformedStreamException: > Header section has more than 10240 bytes (maybe it is not properly > terminated) > at org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:542) > at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:976) > at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:942) > at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331) > at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349) > at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126) > at org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) > at org.swordapp.server.SwordAPIEndpoint.addDepositPropertiesFromMultipart(SwordAPIEndpoint.java:235) > at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:152) > at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:770) > at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) > at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) > at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:679) > > org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) > is this line... > > List<DiskFileItem> items = upload.parseRequest(request); > > ... which can be seen at > https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L496 > > > -- > Philip Durbin > Software Developer for http://thedata.org > http://www.iq.harvard.edu/people/philip-durbin > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
From: Philip D. <phi...@ha...> - 2013-07-10 21:42:17
|
Very helpful, thanks, Eddie. I see one of your commit comments is this... "Best as I can tell, commons-fileupload doesn't actually handle multipart/related correctly. This is currently a naive hack that reads everything into memory, but it at least parses multipart/related correctly (if you have the heap space)." I wonder what you think about this comment from http://irclog.greptilian.com/sourcefu/2013-07-10#i_10152 ... "semiosis: side note, servlet 3 supports multipart, no need for apache commons multipart anymore" Phil On Wed, Jul 10, 2013 at 5:28 PM, Edwin Shin <edw...@yo...> wrote: > Philip, > > If this is related to, ahem, multipart-related support, that simply didn't work in swordapp (at least last year). It was one of the issues I addressed in my fork, see: > > https://github.com/mediashelf/sword2-server/commit/5458968f7d4e73c76bd35c18f6d4102d99663db3 > > https://github.com/mediashelf/sword2-server/commit/1f6c677c36b409cb929370df31d28e162cf56632 > > -Eddie > > On Jul 10, 2013, at 5:05 PM, Philip Durbin <phi...@ha...> wrote: > >> I'm still using sword2-server-1.0-classes.jar and got a strange >> exception today when trying to make deposit.isMultipart() true with >> the proper arguments to curl. >> >> I'm able to reproduce the exception in my Vagrant environment so I >> just added this issue: >> >> MalformedStreamException with Content-Type: multipart/related · Issue >> #2 · dvn/swordpoc - https://github.com/dvn/swordpoc/issues/2 >> >> Anyway, I'm still investigating this but I thought I'd bring it up >> while it's on my mind. >> >> Before working on this too hard I'll probably return to cases where >> deposit.isBinaryOnly() or deposit.isEntryOnly() is true... seems like >> I'll want to get multipart working eventually though... >> >> Phil >> >> p.s. Here's what I wrote in that issue #2: >> >> While looking at isMultipart() in >> https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/Deposit.java >> I attempted to use curl to upload multipart.dat from >> https://github.com/swordapp/Simple-Sword-Server/blob/master/tests/resources/multipart.dat >> with these commands... >> >> wget https://raw.github.com/swordapp/Simple-Sword-Server/master/tests/resources/multipart.dat >> curl --insecure --data-binary "@multipart.dat" -H 'Content-Type: >> multipart/related; boundary="===============0670350989=="' -H >> "MIME-Version: 1.0" >> https://sword:sword@localhost:8181/swordpoc/collection/a4f21cdc-f20c-4c82-b63e-5df81f809417 >> >> ... and got this exception: >> >> [#|2013-07-10T21:39:34.677+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-2;|StandardWrapperValve[collection]: >> PWC1406: Servlet.service() for servlet collection threw exception >> org.apache.commons.fileupload.MultipartStream$MalformedStreamException: >> Header section has more than 10240 bytes (maybe it is not properly >> terminated) >> at org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:542) >> at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:976) >> at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:942) >> at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331) >> at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349) >> at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126) >> at org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) >> at org.swordapp.server.SwordAPIEndpoint.addDepositPropertiesFromMultipart(SwordAPIEndpoint.java:235) >> at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:152) >> at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:770) >> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550) >> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) >> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) >> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) >> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) >> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) >> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) >> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) >> at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) >> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) >> at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) >> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) >> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) >> at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) >> at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) >> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) >> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) >> at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) >> at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) >> at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) >> at com.sun.grizzly.ContextTask.run(ContextTask.java:71) >> at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) >> at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) >> at java.lang.Thread.run(Thread.java:679) >> >> org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) >> is this line... >> >> List<DiskFileItem> items = upload.parseRequest(request); >> >> ... which can be seen at >> https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L496 >> >> >> -- >> Philip Durbin >> Software Developer for http://thedata.org >> http://www.iq.harvard.edu/people/philip-durbin >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Philip D. <phi...@ha...> - 2013-07-10 20:05:25
|
I'm still using sword2-server-1.0-classes.jar and got a strange exception today when trying to make deposit.isMultipart() true with the proper arguments to curl. I'm able to reproduce the exception in my Vagrant environment so I just added this issue: MalformedStreamException with Content-Type: multipart/related · Issue #2 · dvn/swordpoc - https://github.com/dvn/swordpoc/issues/2 Anyway, I'm still investigating this but I thought I'd bring it up while it's on my mind. Before working on this too hard I'll probably return to cases where deposit.isBinaryOnly() or deposit.isEntryOnly() is true... seems like I'll want to get multipart working eventually though... Phil p.s. Here's what I wrote in that issue #2: While looking at isMultipart() in https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/Deposit.java I attempted to use curl to upload multipart.dat from https://github.com/swordapp/Simple-Sword-Server/blob/master/tests/resources/multipart.dat with these commands... wget https://raw.github.com/swordapp/Simple-Sword-Server/master/tests/resources/multipart.dat curl --insecure --data-binary "@multipart.dat" -H 'Content-Type: multipart/related; boundary="===============0670350989=="' -H "MIME-Version: 1.0" https://sword:sword@localhost:8181/swordpoc/collection/a4f21cdc-f20c-4c82-b63e-5df81f809417 ... and got this exception: [#|2013-07-10T21:39:34.677+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-2;|StandardWrapperValve[collection]: PWC1406: Servlet.service() for servlet collection threw exception org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Header section has more than 10240 bytes (maybe it is not properly terminated) at org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:542) at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:976) at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:942) at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349) at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126) at org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) at org.swordapp.server.SwordAPIEndpoint.addDepositPropertiesFromMultipart(SwordAPIEndpoint.java:235) at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:152) at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at javax.servlet.http.HttpServlet.service(HttpServlet.java:770) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:679) org.swordapp.server.SwordAPIEndpoint.getPartsFromRequest(SwordAPIEndpoint.java:496) is this line... List<DiskFileItem> items = upload.parseRequest(request); ... which can be seen at https://github.com/swordapp/JavaServer2.0/blob/314f4dab35d801397be3e0c5a9c7e53c4b736bef/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L496 -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: LEWIS S. <Stu...@ed...> - 2013-07-01 07:28:03
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Jonathan A. <jon...@gm...> - 2013-06-29 02:47:50
|
Hi, Is there any way to deposit with atom format through php sword 1 library ? Thanks, Jonathan |
From: Philip D. <phi...@ha...> - 2013-06-28 21:05:32
|
On Thu, Jun 27, 2013 at 10:53 AM, Philip Durbin <phi...@ha...> wrote: > Before the jar gets published, I believe I may have found a bug here: > > https://github.com/swordapp/JavaServer2.0/blob/31e625ac97be13f794e1b98512f8d1c48d751652/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L435 > > When I use the following command... > > curl --insecure -s -H "X-On-Behalf-Of: obo" --http1.0 --data-binary > "@example.zip" -H "Content-Disposition: filename=example.zip" -H > "Content-Type: application/zip" > https://sword:sword@localhost:8181/swordpoc/collection/a4f21cdc-f20c-4c82-b63e-5df81f809417 > > ... my "example.zip" file gets uploaded as "xample.zip" (i.e. the > first character is removed). I can easily reproduce this in Vagrant > with https://github.com/dvn/swordpoc if you'd like more detail. FYI, this bug has been confirmed by Bill McKinney who has submitted a pull request called "enhanced content disposition handling": https://github.com/swordapp/JavaServer2.0/pull/2 For my part, I'm moved my proof of concept code into an experimental branch in our app itself: https://github.com/IQSS/dvn/commit/4838565 I can keep https://github.com/dvn/swordpoc around for anyone who wants to see the library exercised a bit with some working code. Phil -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Philip D. <phi...@ha...> - 2013-06-27 14:53:14
|
On Fri, Jun 21, 2013 at 5:29 AM, Richard Jones <ri...@co...> wrote: > We probably need to get together a how-to or tutorial in using the > code. If you can document your experiences with it, we'd be very > interested in including that into a README or a github page for the > software. Sure, as I go along I'm updating the readme at https://github.com/dvn/swordpoc >> One issue I'm having is finding a published version of that >> org.swordapp:sword2-server jar. Do you plan to publish it on Maven >> Central? For now, I'm building it myself but I opened >> https://github.com/dvn/swordpoc/issues/1 to remind myself to follow up >> on this. > > Yes, I haven't done this yet, but we will need to do it in order for > the new code for DSpace to be accepted into the main release. I don't > have a lot of experience with publishing maven artifacts, so up until > now I've been just installing it into my local maven repository when > using it. Glad to accept any help in getting it done! Hmm, I actually don't have any experience publishing to Maven Central. I'm not sure how hard it is. Before the jar gets published, I believe I may have found a bug here: https://github.com/swordapp/JavaServer2.0/blob/31e625ac97be13f794e1b98512f8d1c48d751652/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L435 When I use the following command... curl --insecure -s -H "X-On-Behalf-Of: obo" --http1.0 --data-binary "@example.zip" -H "Content-Disposition: filename=example.zip" -H "Content-Type: application/zip" https://sword:sword@localhost:8181/swordpoc/collection/a4f21cdc-f20c-4c82-b63e-5df81f809417 ... my "example.zip" file gets uploaded as "xample.zip" (i.e. the first character is removed). I can easily reproduce this in Vagrant with https://github.com/dvn/swordpoc if you'd like more detail. Phil -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Philip D. <phi...@ha...> - 2013-06-24 14:41:14
|
Thanks for this, Eddie. I just added it to my list of SWORD implementations: http://devguide.thedata.org/features/api/data-deposit I like how you've separated out your implementation (i.e. FedoraCollectionDepositManager) from the server/library code. Different projects, different git repos. I'm planning on doing the same. On Thu, Jun 20, 2013 at 12:14 PM, Edwin Shin <edw...@yo...> wrote: > Phil, > > There's also the fork of JavaServer2.0 that I did last year: > > https://github.com/mediashelf/sword2-server > > which changed the packaging from war to jar, implemented multipart/related support and some general maven/dependency maintenance. > > I did that as part of a very limited implementation of SWORD 2 for Fedora: > > https://github.com/mediashelf/sword2-fedora > > -Eddie > > On Jun 20, 2013, at 3:22 PM, LEWIS Stuart <Stu...@ed...> wrote: > >> Hi Phil, >> >>> I forked https://github.com/swordapp/JavaServer2.0 and implemented the >>> very minimal number of interfaces to get it to respond to some basic >>> SWORD v2 operations such as retrieving a (fake) service document and >>> (the very beginnings of) depositing a binary. >> >>> I called the repo "Minimal viable SWORD v2 server implemented in Java" >>> (though it's hardly viable) and you can find it at >>> https://github.com/dvn/swordv2-java-minimal >> >> Thanks for sharing this. The JavaServer.20 was originally written as part of the DSpace SWORDv2 implementation, but it was thought at the time it would be worth abstracting out the SWORD part from DSpace part, in the hope that this might be reusable. As far as I know, you're the first person to try using outside of DSpace (hence the lack of any other implementation or past experience). >> >> Richard Jones wrote this and may be able to give you a few pointers, however he is offline this week at a conference (OAI8 in Geneva). If you're attending Open Repositories next month, I'm sure he'd be happy to say hello and talk more about the code. >> >> >>> p.s. I'm growing concerned that this mailing list is so quiet (and >>> only admins can see the number of people subscribed). Have people >>> moved on from SWORD to some other standard? If so, which one? >> >> I just checked - there are 175 subscribers to this list. >> >> As far as I know, SWORD is the main contender in town when it comes to a standardized deposit interface to this type of repository. I've also wondered about the quietness of this list. I think there may be a few reasons: one, is that a lot of repository users are still grappling with their repositories, without yet getting as far as accepting remote deposits. Second, SWORD doesn't yet really have an active community sharing deposit tools. Partly this is because many uses of SWORD will be very specific point-to-point integrations, which might not be of interest to too many others. >> >> It would be good to hear a wider discussion about this, and how we share more about our individual uses of SWORD. >> >> Thanks, >> >> >> >> Stuart Lewis >> Head of Research and Learning Services >> Deputy Director Library & University Collections, Information Services >> University of Edinburgh >> Stu...@ed... >> -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Richard J. <ri...@co...> - 2013-06-21 09:29:23
|
Hi Phil, >> Phil - it sounds like you've got a handle on things with regard to the >> reference implementation. The JavaServer2.0 was written in parallel >> to the DSpace implementation (as Stuart says), to provide the generic >> parsing and serialising of sword protocol operations. Hopefully I've >> successfully separated the concerns of the standard from the concerns >> of DSpace, but I'd be interested in your feedback. > > It's somewhat slow going, but I'm not blocked on anything. I'm very > glad SWORD v2 servers have already been implemented in Java! We probably need to get together a how-to or tutorial in using the code. If you can document your experiences with it, we'd be very interested in including that into a README or a github page for the software. > I had mentioned https://github.com/dvn/swordv2-java-minimal previously > which is a fork of your https://github.com/swordapp/JavaServer2.0 but > I wanted to move the code into its own project so I could use the > org.swordapp:sword2-server jar as a library as it's intended. Toward > this end I made a new Java project under edu.harvard.iq namespace and > added the code into https://github.com/dvn/swordpoc and updated the > readme to explain how to build and deploy it into the provided Vagrant > environment. > > One issue I'm having is finding a published version of that > org.swordapp:sword2-server jar. Do you plan to publish it on Maven > Central? For now, I'm building it myself but I opened > https://github.com/dvn/swordpoc/issues/1 to remind myself to follow up > on this. Yes, I haven't done this yet, but we will need to do it in order for the new code for DSpace to be accepted into the main release. I don't have a lot of experience with publishing maven artifacts, so up until now I've been just installing it into my local maven repository when using it. Glad to accept any help in getting it done! > I'm sure I'll have more feedback as time goes on. At a high level, > we're hoping to use SWORD v2 as the protocol that allows Open Journal > Systems to deposit data into a Dataverse, as described at > http://projects.iq.harvard.edu/ojs-dvn/book/faq-ojs-dataverse-integration-project Excellent - really cool to see this kind of thing happening! Cheers, Richard -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
From: Edwin S. <edw...@yo...> - 2013-06-20 16:44:10
|
Phil, There's also the fork of JavaServer2.0 that I did last year: https://github.com/mediashelf/sword2-server which changed the packaging from war to jar, implemented multipart/related support and some general maven/dependency maintenance. I did that as part of a very limited implementation of SWORD 2 for Fedora: https://github.com/mediashelf/sword2-fedora -Eddie On Jun 20, 2013, at 3:22 PM, LEWIS Stuart <Stu...@ed...> wrote: > Hi Phil, > >> I forked https://github.com/swordapp/JavaServer2.0 and implemented the >> very minimal number of interfaces to get it to respond to some basic >> SWORD v2 operations such as retrieving a (fake) service document and >> (the very beginnings of) depositing a binary. > >> I called the repo "Minimal viable SWORD v2 server implemented in Java" >> (though it's hardly viable) and you can find it at >> https://github.com/dvn/swordv2-java-minimal > > Thanks for sharing this. The JavaServer.20 was originally written as part of the DSpace SWORDv2 implementation, but it was thought at the time it would be worth abstracting out the SWORD part from DSpace part, in the hope that this might be reusable. As far as I know, you're the first person to try using outside of DSpace (hence the lack of any other implementation or past experience). > > Richard Jones wrote this and may be able to give you a few pointers, however he is offline this week at a conference (OAI8 in Geneva). If you're attending Open Repositories next month, I'm sure he'd be happy to say hello and talk more about the code. > > >> p.s. I'm growing concerned that this mailing list is so quiet (and >> only admins can see the number of people subscribed). Have people >> moved on from SWORD to some other standard? If so, which one? > > I just checked - there are 175 subscribers to this list. > > As far as I know, SWORD is the main contender in town when it comes to a standardized deposit interface to this type of repository. I've also wondered about the quietness of this list. I think there may be a few reasons: one, is that a lot of repository users are still grappling with their repositories, without yet getting as far as accepting remote deposits. Second, SWORD doesn't yet really have an active community sharing deposit tools. Partly this is because many uses of SWORD will be very specific point-to-point integrations, which might not be of interest to too many others. > > It would be good to hear a wider discussion about this, and how we share more about our individual uses of SWORD. > > Thanks, > > > > Stuart Lewis > Head of Research and Learning Services > Deputy Director Library & University Collections, Information Services > University of Edinburgh > Stu...@ed... > |
From: Philip D. <phi...@ha...> - 2013-06-20 16:02:57
|
On Thu, Jun 20, 2013 at 4:41 AM, Richard Jones <ri...@co...> wrote: > > Phil - it sounds like you've got a handle on things with regard to the > reference implementation. The JavaServer2.0 was written in parallel > to the DSpace implementation (as Stuart says), to provide the generic > parsing and serialising of sword protocol operations. Hopefully I've > successfully separated the concerns of the standard from the concerns > of DSpace, but I'd be interested in your feedback. It's somewhat slow going, but I'm not blocked on anything. I'm very glad SWORD v2 servers have already been implemented in Java! I had mentioned https://github.com/dvn/swordv2-java-minimal previously which is a fork of your https://github.com/swordapp/JavaServer2.0 but I wanted to move the code into its own project so I could use the org.swordapp:sword2-server jar as a library as it's intended. Toward this end I made a new Java project under edu.harvard.iq namespace and added the code into https://github.com/dvn/swordpoc and updated the readme to explain how to build and deploy it into the provided Vagrant environment. One issue I'm having is finding a published version of that org.swordapp:sword2-server jar. Do you plan to publish it on Maven Central? For now, I'm building it myself but I opened https://github.com/dvn/swordpoc/issues/1 to remind myself to follow up on this. I'm sure I'll have more feedback as time goes on. At a high level, we're hoping to use SWORD v2 as the protocol that allows Open Journal Systems to deposit data into a Dataverse, as described at http://projects.iq.harvard.edu/ojs-dvn/book/faq-ojs-dataverse-integration-project Phil -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Richard J. <ri...@co...> - 2013-06-20 13:46:38
|
Hi Jonathan, When you say the "real ID" do you mean the item's database identifier, or the handle that DSpace assigns to the item? Presuming that you mean the latter, you can find this in the atom:link@rel="alternate" field of the deposit receipt, but only in the case that the deposited item goes directly into the archive. If there is a review workflow set up on the collection you deposited to, the item will go into that review workflow. As a consequence, there is no handle for the item at the time the receipt is returned to you after the deposit operation. If you are using the standard DSpace version of SWORDv2, this means you /will not/ be able to get a url for the item as it is in DSpace at that time. All you can do is wait for the review workflow to complete, and then query the Edit-IRI again, to see if the atom:link@rel="alternate" has been populated, which is will be once the item is assigned a handle. Hope that helps, Cheers, Richard On 18 June 2013 15:52, Philip Durbin <phi...@ha...> wrote: > On Mon, Jun 17, 2013 at 5:04 PM, Jonathan Alba > <jon...@gm...> wrote: >> I'm having problems when I deposit a object in DSpace. I need to retrieve >> the real ID of the object, but the ID returned is different. It seems to me >> that it is an internal ID of SWORD. Does anyone know how to recover the true >> object ID? > > You might be able to determine this by studying this code: > > https://github.com/DSpace/DSpace/tree/master/dspace-swordv2/src/main/java/org/dspace/sword2 > > In #dspace on Freenode yesterday I was told this is the implementation > DSpace uses. > > I'm sorry I can't be of more assistance. I'm just learning about SWORD > and I've never used DSpace. > > Phil > > p.s. I noticed that the message above from Jonathan (and one I sent > yesterday morning) has not yet been archived at > http://sourceforge.net/mailarchive/forum.php?forum_name=sword-app-tech > but it looks like it was properly archived at > http://www.mail-archive.com/swo...@li.../msg00307.html > > -- > Philip Durbin > Software Developer for http://thedata.org > http://www.iq.harvard.edu/people/philip-durbin > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
From: Richard J. <ri...@co...> - 2013-06-20 09:13:15
|
Hi Folks, Phil - it sounds like you've got a handle on things with regard to the reference implementation. The JavaServer2.0 was written in parallel to the DSpace implementation (as Stuart says), to provide the generic parsing and serialising of sword protocol operations. Hopefully I've successfully separated the concerns of the standard from the concerns of DSpace, but I'd be interested in your feedback. >> p.s. I'm growing concerned that this mailing list is so quiet (and >> only admins can see the number of people subscribed). Have people >> moved on from SWORD to some other standard? If so, which one? > > I just checked - there are 175 subscribers to this list. > > As far as I know, SWORD is the main contender in town when it comes to a standardized deposit interface to this type of repository. I've also wondered about the quietness of this list. I think there may be a few reasons: one, is that a lot of repository users are still grappling with their repositories, without yet getting as far as accepting remote deposits. Second, SWORD doesn't yet really have an active community sharing deposit tools. Partly this is because many uses of SWORD will be very specific point-to-point integrations, which might not be of interest to too many others. > > It would be good to hear a wider discussion about this, and how we share more about our individual uses of SWORD. I think one of the main issues is exactly where to ask about what. Because SWORD is a standard, but the technical questions are really about implementations, where is the best place to post about problems? For example, if the problems are specifically with the DSpace implementation of SWORD, it is /probably/ better to ask on dspace-dev. Also, because we're in the early stages of community development with SWORD, Stuart and I are a bit of a bottleneck on this list - usually one of us is required to respond, and if we're unavailable for any length of time (e.g. I've been travelling for nearly 2 weeks now, and am emailing from the fourth row of a session at OAI8 right now :) ), then the list looks dead. We are hoping to have some discussions around sword sustainability with Jisc quite soon which community development and support like this is going to be a key part of. Very interested in people's thoughts as to how to make things better. Cheers, Richard -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
From: Richard J. <ri...@co...> - 2013-06-20 09:11:40
|
Hi Folks, So, spurred on by Phil and Stuart, I also should share some more about SWORD related developments. I've been working on a project to integrate the norwegian student theses system with DSpace (and in particular the University of Oslo's research archive) using SWORD. This has resulted in an enhanced SWORDv2 implementation for DSpace, which is available as a separate module here: https://github.com/swordapp/DSpaceSWORDv2 I'm currently discussing with the rest of the DSpace committers the process of getting that into DSpace 4: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes Cheers, Richard -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
From: Richard J. <ri...@co...> - 2013-06-20 09:08:52
|
I showed off the results of this work at OAI8 this week, and it was quite well received. I didn't get a chance to actually do a live demo, unfortunately. There is also a noticeable increase in interest around SWORD this year, and I've been approached by a number of people at OAI8 wanting to provide the relevant integration with their repositories. Cheers, Richard On 20 June 2013 08:30, LEWIS Stuart <Stu...@ed...> wrote: > Hi all, > > > > Phil Durbin’s email reminded me that it is good to share some of the work > each of us is doing with SWORD. I’ve recently been working on a SWORD > implementation to sync resources using ResourceSync. > > > > The idea behind this was to test out the proposed ResourceSync standard > (http://www.niso.org/workrooms/resourcesync/ and > http://www.openarchives.org/rs/) by pushing the synchronised resources back > into another repository. SWORDv2 allows ResourceSync’s “changelists” to be > mirrored in the remote repository, by processing the relevant updates and > deletes. > > > > This requires a bit of work to merge related items in a ResourceSync, so > that metadata items and their related files are deposited together. > > > > There is a write-up at: > > > > http://blog.stuartlewis.com/tag/resourcesync/ > > > > For background reading, > http://cottagelabs.com/news/meeting-the-oaipmh-use-case-with-resourcesync is > useful. > > > > Comments welcome! > > > > Thanks, > > > > > > Stuart Lewis > > Head of Research and Learning Services > > Deputy Director Library & University Collections, Information Services > > University of Edinburgh > > Stu...@ed... > > > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
From: LEWIS S. <Stu...@ed...> - 2013-06-20 07:30:44
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: LEWIS S. <Stu...@ed...> - 2013-06-20 07:23:05
|
Hi Phil, > I forked https://github.com/swordapp/JavaServer2.0 and implemented the > very minimal number of interfaces to get it to respond to some basic > SWORD v2 operations such as retrieving a (fake) service document and > (the very beginnings of) depositing a binary. > I called the repo "Minimal viable SWORD v2 server implemented in Java" > (though it's hardly viable) and you can find it at > https://github.com/dvn/swordv2-java-minimal Thanks for sharing this. The JavaServer.20 was originally written as part of the DSpace SWORDv2 implementation, but it was thought at the time it would be worth abstracting out the SWORD part from DSpace part, in the hope that this might be reusable. As far as I know, you're the first person to try using outside of DSpace (hence the lack of any other implementation or past experience). Richard Jones wrote this and may be able to give you a few pointers, however he is offline this week at a conference (OAI8 in Geneva). If you're attending Open Repositories next month, I'm sure he'd be happy to say hello and talk more about the code. > p.s. I'm growing concerned that this mailing list is so quiet (and > only admins can see the number of people subscribed). Have people > moved on from SWORD to some other standard? If so, which one? I just checked - there are 175 subscribers to this list. As far as I know, SWORD is the main contender in town when it comes to a standardized deposit interface to this type of repository. I've also wondered about the quietness of this list. I think there may be a few reasons: one, is that a lot of repository users are still grappling with their repositories, without yet getting as far as accepting remote deposits. Second, SWORD doesn't yet really have an active community sharing deposit tools. Partly this is because many uses of SWORD will be very specific point-to-point integrations, which might not be of interest to too many others. It would be good to hear a wider discussion about this, and how we share more about our individual uses of SWORD. Thanks, Stuart Lewis Head of Research and Learning Services Deputy Director Library & University Collections, Information Services University of Edinburgh Stu...@ed... -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Philip D. <phi...@ha...> - 2013-06-20 01:20:48
|
Ok, this is a complete hack but... I forked https://github.com/swordapp/JavaServer2.0 and implemented the very minimal number of interfaces to get it to respond to some basic SWORD v2 operations such as retrieving a (fake) service document and (the very beginnings of) depositing a binary. I called the repo "Minimal viable SWORD v2 server implemented in Java" (though it's hardly viable) and you can find it at https://github.com/dvn/swordv2-java-minimal I had asked previously about SWORD v2 server implementations in Java and it seems the main one is DSpace. I found it very helpful to look at https://github.com/swordapp/DSpaceSWORDv2 though I stripped out anything DSpace-specific in this hack of mine. Phil p.s. I'm growing concerned that this mailing list is so quiet (and only admins can see the number of people subscribed). Have people moved on from SWORD to some other standard? If so, which one? On Mon, Jun 17, 2013 at 12:59 PM, Philip Durbin <phi...@ha...> wrote: > Anyone out there? :) > > I'd like to get the Java example working but I haven't spent any more > time on it yet. Has anyone implemented SWORD v2 in a server-side Java > app? > > Phil > > p.s. The Python example at > https://github.com/swordapp/Simple-Sword-Server seems to work fine... > I verified it in a Vagrant environment I just created: > https://github.com/dvn/swordpoc > > p.p.s. For some more background... we are hoping to comply with SWORD > v2 in the data deposit API we're working on for our Java EE > application (Dataverse Network): > https://redmine.hmdc.harvard.edu/issues/3108 > > On Fri, Jun 14, 2013 at 4:32 PM, Philip Durbin > <phi...@ha...> wrote: >> As a sanity check... I should be able to deploy JavaServer2.0 and have >> have JavaClient2.0 talk to it, right? >> >> Phil >> >> p.s. These: >> >> - https://github.com/swordapp/JavaServer2.0 >> - https://github.com/swordapp/JavaClient2.0 >> >> p.p.s. More info on what I'm trying (what is BagIt.zip?): >> >> murphy:JavaClient2.0 pdurbin$ git diff src >> diff --git a/src/main/java/org/swordapp/client/SwordCli.java >> b/src/main/java/org/swordapp/client/SwordCli.java >> index 8358c10..be47a87 100644 >> --- a/src/main/java/org/swordapp/client/SwordCli.java >> +++ b/src/main/java/org/swordapp/client/SwordCli.java >> @@ -19,9 +19,9 @@ public class SwordCli >> private String exampleZip = "/Users/richard/Code/External/SSS/example.zip"; >> private String image = >> "/Users/richard/Code/Internal/DepositMO/Dome_sm.jpg"; >> private String docx = "/Users/richard/Code/Internal/DepositMO/hy.docx"; >> - private String bagit = "/Users/richard/Dropbox/Documents/DUO/BagIt.zip"; >> + private String bagit = "/tmp/BagIt.zip"; >> //private String sdIRI = "http://localhost:8080/sd-uri"; >> - private String sdIRI = "http://localhost:8080/swordv2/servicedocument"; >> + private String sdIRI = >> "http://localhost:8080/JavaServer2.0/servicedocument"; >> private String user = "richard"; >> private String pass = "dspace"; >> private String obo = null; >> murphy:JavaClient2.0 pdurbin$ >> murphy:JavaClient2.0 pdurbin$ java -jar target/sword2-client-0.9.2.jar >> tryFSDeposit >> INFO [main] (SWORDClient.java:1561) - Requesting Service Document >> from http://localhost:8080/JavaServer2.0/servicedocument with username >> richard >> WARN [main] (SWORDClient.java:154) - Unable to retrieve service >> document from http://localhost:8080/JavaServer2.0/servicedocument; >> responded with 500. Possible problem with SWORD server, or URL >> Exception in thread "main" java.lang.NullPointerException >> at org.swordapp.client.SwordCli.tryFSDeposit(SwordCli.java:70) >> at org.swordapp.client.SwordCli.main(SwordCli.java:56) >> murphy:JavaClient2.0 pdurbin$ >> murphy:JavaClient2.0 pdurbin$ curl -s >> http://localhost:8080/JavaServer2.0/servicedocument | elinks -dump >> HTTP Status 500 - >> >> -------------------------------------------------------------------------- >> >> type Exception report >> >> message >> >> descriptionThe server encountered an internal error () that prevented it >> from fulfilling this request. >> >> exception >> >> javax.servlet.ServletException: Unable to instantiate class from >> 'service-document-impl': >> org.swordapp.server.ServiceDocumentManagerImpl >> >> root cause >> >> java.lang.ClassNotFoundException: >> org.swordapp.server.ServiceDocumentManagerImpl >> >> note The full stack traces of the exception and its root causes are >> available in the GlassFish Server Open Source Edition 3.1.2.2 logs. >> >> -------------------------------------------------------------------------- >> >> GlassFish Server Open Source Edition 3.1.2.2 >> murphy:JavaClient2.0 pdurbin$ >> murphy:JavaClient2.0 pdurbin$ git log --oneline | head -1 >> 056f545 add mets deposit tests and associated resources >> >> p.p.p.s. Nobody is in #swordapp on freenode :( ... should we start it? :) >> >> -- >> Philip Durbin >> Software Developer for http://thedata.org >> http://www.iq.harvard.edu/people/philip-durbin > > > > -- > Philip Durbin > Software Developer for http://thedata.org > http://www.iq.harvard.edu/people/philip-durbin -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Philip D. <phi...@ha...> - 2013-06-18 14:59:32
|
On Mon, Jun 17, 2013 at 5:04 PM, Jonathan Alba <jon...@gm...> wrote: > I'm having problems when I deposit a object in DSpace. I need to retrieve > the real ID of the object, but the ID returned is different. It seems to me > that it is an internal ID of SWORD. Does anyone know how to recover the true > object ID? You might be able to determine this by studying this code: https://github.com/DSpace/DSpace/tree/master/dspace-swordv2/src/main/java/org/dspace/sword2 In #dspace on Freenode yesterday I was told this is the implementation DSpace uses. I'm sorry I can't be of more assistance. I'm just learning about SWORD and I've never used DSpace. Phil p.s. I noticed that the message above from Jonathan (and one I sent yesterday morning) has not yet been archived at http://sourceforge.net/mailarchive/forum.php?forum_name=sword-app-tech but it looks like it was properly archived at http://www.mail-archive.com/swo...@li.../msg00307.html -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Jonathan A. <jon...@gm...> - 2013-06-17 21:04:50
|
Hi, I'm having problems when I deposit a object in DSpace. I need to retrieve the real ID of the object, but the ID returned is different. It seems to me that it is an internal ID of SWORD. Does anyone know how to recover the true object ID? Thanks, Jonathan |
From: Philip D. <phi...@ha...> - 2013-06-17 16:59:29
|
Anyone out there? :) I'd like to get the Java example working but I haven't spent any more time on it yet. Has anyone implemented SWORD v2 in a server-side Java app? Phil p.s. The Python example at https://github.com/swordapp/Simple-Sword-Server seems to work fine... I verified it in a Vagrant environment I just created: https://github.com/dvn/swordpoc p.p.s. For some more background... we are hoping to comply with SWORD v2 in the data deposit API we're working on for our Java EE application (Dataverse Network): https://redmine.hmdc.harvard.edu/issues/3108 On Fri, Jun 14, 2013 at 4:32 PM, Philip Durbin <phi...@ha...> wrote: > As a sanity check... I should be able to deploy JavaServer2.0 and have > have JavaClient2.0 talk to it, right? > > Phil > > p.s. These: > > - https://github.com/swordapp/JavaServer2.0 > - https://github.com/swordapp/JavaClient2.0 > > p.p.s. More info on what I'm trying (what is BagIt.zip?): > > murphy:JavaClient2.0 pdurbin$ git diff src > diff --git a/src/main/java/org/swordapp/client/SwordCli.java > b/src/main/java/org/swordapp/client/SwordCli.java > index 8358c10..be47a87 100644 > --- a/src/main/java/org/swordapp/client/SwordCli.java > +++ b/src/main/java/org/swordapp/client/SwordCli.java > @@ -19,9 +19,9 @@ public class SwordCli > private String exampleZip = "/Users/richard/Code/External/SSS/example.zip"; > private String image = > "/Users/richard/Code/Internal/DepositMO/Dome_sm.jpg"; > private String docx = "/Users/richard/Code/Internal/DepositMO/hy.docx"; > - private String bagit = "/Users/richard/Dropbox/Documents/DUO/BagIt.zip"; > + private String bagit = "/tmp/BagIt.zip"; > //private String sdIRI = "http://localhost:8080/sd-uri"; > - private String sdIRI = "http://localhost:8080/swordv2/servicedocument"; > + private String sdIRI = > "http://localhost:8080/JavaServer2.0/servicedocument"; > private String user = "richard"; > private String pass = "dspace"; > private String obo = null; > murphy:JavaClient2.0 pdurbin$ > murphy:JavaClient2.0 pdurbin$ java -jar target/sword2-client-0.9.2.jar > tryFSDeposit > INFO [main] (SWORDClient.java:1561) - Requesting Service Document > from http://localhost:8080/JavaServer2.0/servicedocument with username > richard > WARN [main] (SWORDClient.java:154) - Unable to retrieve service > document from http://localhost:8080/JavaServer2.0/servicedocument; > responded with 500. Possible problem with SWORD server, or URL > Exception in thread "main" java.lang.NullPointerException > at org.swordapp.client.SwordCli.tryFSDeposit(SwordCli.java:70) > at org.swordapp.client.SwordCli.main(SwordCli.java:56) > murphy:JavaClient2.0 pdurbin$ > murphy:JavaClient2.0 pdurbin$ curl -s > http://localhost:8080/JavaServer2.0/servicedocument | elinks -dump > HTTP Status 500 - > > -------------------------------------------------------------------------- > > type Exception report > > message > > descriptionThe server encountered an internal error () that prevented it > from fulfilling this request. > > exception > > javax.servlet.ServletException: Unable to instantiate class from > 'service-document-impl': > org.swordapp.server.ServiceDocumentManagerImpl > > root cause > > java.lang.ClassNotFoundException: > org.swordapp.server.ServiceDocumentManagerImpl > > note The full stack traces of the exception and its root causes are > available in the GlassFish Server Open Source Edition 3.1.2.2 logs. > > -------------------------------------------------------------------------- > > GlassFish Server Open Source Edition 3.1.2.2 > murphy:JavaClient2.0 pdurbin$ > murphy:JavaClient2.0 pdurbin$ git log --oneline | head -1 > 056f545 add mets deposit tests and associated resources > > p.p.p.s. Nobody is in #swordapp on freenode :( ... should we start it? :) > > -- > Philip Durbin > Software Developer for http://thedata.org > http://www.iq.harvard.edu/people/philip-durbin -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Philip D. <phi...@ha...> - 2013-06-14 20:57:14
|
As a sanity check... I should be able to deploy JavaServer2.0 and have have JavaClient2.0 talk to it, right? Phil p.s. These: - https://github.com/swordapp/JavaServer2.0 - https://github.com/swordapp/JavaClient2.0 p.p.s. More info on what I'm trying (what is BagIt.zip?): murphy:JavaClient2.0 pdurbin$ git diff src diff --git a/src/main/java/org/swordapp/client/SwordCli.java b/src/main/java/org/swordapp/client/SwordCli.java index 8358c10..be47a87 100644 --- a/src/main/java/org/swordapp/client/SwordCli.java +++ b/src/main/java/org/swordapp/client/SwordCli.java @@ -19,9 +19,9 @@ public class SwordCli private String exampleZip = "/Users/richard/Code/External/SSS/example.zip"; private String image = "/Users/richard/Code/Internal/DepositMO/Dome_sm.jpg"; private String docx = "/Users/richard/Code/Internal/DepositMO/hy.docx"; - private String bagit = "/Users/richard/Dropbox/Documents/DUO/BagIt.zip"; + private String bagit = "/tmp/BagIt.zip"; //private String sdIRI = "http://localhost:8080/sd-uri"; - private String sdIRI = "http://localhost:8080/swordv2/servicedocument"; + private String sdIRI = "http://localhost:8080/JavaServer2.0/servicedocument"; private String user = "richard"; private String pass = "dspace"; private String obo = null; murphy:JavaClient2.0 pdurbin$ murphy:JavaClient2.0 pdurbin$ java -jar target/sword2-client-0.9.2.jar tryFSDeposit INFO [main] (SWORDClient.java:1561) - Requesting Service Document from http://localhost:8080/JavaServer2.0/servicedocument with username richard WARN [main] (SWORDClient.java:154) - Unable to retrieve service document from http://localhost:8080/JavaServer2.0/servicedocument; responded with 500. Possible problem with SWORD server, or URL Exception in thread "main" java.lang.NullPointerException at org.swordapp.client.SwordCli.tryFSDeposit(SwordCli.java:70) at org.swordapp.client.SwordCli.main(SwordCli.java:56) murphy:JavaClient2.0 pdurbin$ murphy:JavaClient2.0 pdurbin$ curl -s http://localhost:8080/JavaServer2.0/servicedocument | elinks -dump HTTP Status 500 - -------------------------------------------------------------------------- type Exception report message descriptionThe server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Unable to instantiate class from 'service-document-impl': org.swordapp.server.ServiceDocumentManagerImpl root cause java.lang.ClassNotFoundException: org.swordapp.server.ServiceDocumentManagerImpl note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1.2.2 logs. -------------------------------------------------------------------------- GlassFish Server Open Source Edition 3.1.2.2 murphy:JavaClient2.0 pdurbin$ murphy:JavaClient2.0 pdurbin$ git log --oneline | head -1 056f545 add mets deposit tests and associated resources p.p.p.s. Nobody is in #swordapp on freenode :( ... should we start it? :) -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin |
From: Jonathan A. <jon...@gm...> - 2013-05-02 20:13:28
|
Hi, Removing the @ appear more errors: *Warning*: SimpleXMLElement::__construct(): Entity: line 37: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xE9 0x20 0x72 0x65 in * C:\xampp\htdocs\localhost\sword\swordappv2-php-library-master\swordappservicedocument.php * on line *92* *Warning*: SimpleXMLElement::__construct(): +xml</accept><collectionPolicy xmlns="http://purl.org/net/sword/terms/">O autor in * C:\xampp\htdocs\localhost\sword\swordappv2-php-library-master\swordappservicedocument.php * on line *92* *Warning*: SimpleXMLElement::__construct(): ^ in * C:\xampp\htdocs\localhost\sword\swordappv2-php-library-master\swordappservicedocument.php * on line *92* I solved this by adding the following line: *$sac_thexml = utf8_encode($sac_thexml);* $sac_xml = new SimpleXMLElement($sac_thexml); $sac_ns = $sac_xml->getNamespaces(true); Thanks, Jonathan 2013/4/30 LEWIS Stuart <Stu...@ed...> > Hi Jonathan, > > With SWORDv1, just perform a deposit, but without adding files. If you're > using the METS/SWAP packager, this should just work. Let us know if not. > > Thanks, > > > Stuart Lewis > Head of Research and Learning Services > Deputy Director Library & University Collections, Information Services > University of Edinburgh > Stu...@ed...<mailto:Stu...@ed...> > > From: Jonathan Alba <jon...@gm...<mailto: > jon...@gm...>> > Date: Monday, 29 April 2013 19:51 > To: Lewis Stuart <stu...@ed...<mailto:stu...@ed...>> > Cc: "swo...@li...<mailto: > swo...@li...>" < > swo...@li...<mailto: > swo...@li...>> > Subject: Re: [sword-app-tech] SWORD v2 - Error parsing service document > > Hi Stuart, > > These features already are implemented in SWORD v1 php library, or should > I implement following the sword specification? > Is there any example of deposit with no files in sword v1 ? > > Thanks, > > Jonathan > > > 2013/4/29 LEWIS Stuart <Stu...@ed...<mailto:Stu...@ed... > >> > Hi Jonathan, > > I'll take a look at your service document and reply shortly. To answer > your other questions: > > > I have some other questions, in my dissertation I proposed some features > for the SWORD client: > > 1. Deposit a learning object with no files, only with metadata. > > Yes – SWORD is agnostic about what it deposits. It could deposit just > file(s), just metadata, or both. Both versions of SWORD allow this. SWORD > v2 is more specific in the specification about it, with the deposit of a > basic Dublin Core record being given as an example: > > - > http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_entry > > > 2. Using custom metadata for the deposit. > > Again, SWORD doesn't mind about what it deposits. As long as the SWORD > client and server can both handle a custom metadata format, that is fine. > > Thanks, > > > Stuart Lewis > University of Edinburgh > Stu...@ed...<mailto:Stu...@ed...><mailto: > Stu...@ed...<mailto:Stu...@ed...>> > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > |
From: LEWIS S. <Stu...@ed...> - 2013-04-30 19:11:48
|
Hi Jonathan, With SWORDv1, just perform a deposit, but without adding files. If you're using the METS/SWAP packager, this should just work. Let us know if not. Thanks, Stuart Lewis Head of Research and Learning Services Deputy Director Library & University Collections, Information Services University of Edinburgh Stu...@ed...<mailto:Stu...@ed...> From: Jonathan Alba <jon...@gm...<mailto:jon...@gm...>> Date: Monday, 29 April 2013 19:51 To: Lewis Stuart <stu...@ed...<mailto:stu...@ed...>> Cc: "swo...@li...<mailto:swo...@li...>" <swo...@li...<mailto:swo...@li...>> Subject: Re: [sword-app-tech] SWORD v2 - Error parsing service document Hi Stuart, These features already are implemented in SWORD v1 php library, or should I implement following the sword specification? Is there any example of deposit with no files in sword v1 ? Thanks, Jonathan 2013/4/29 LEWIS Stuart <Stu...@ed...<mailto:Stu...@ed...>> Hi Jonathan, I'll take a look at your service document and reply shortly. To answer your other questions: > I have some other questions, in my dissertation I proposed some features for the SWORD client: > 1. Deposit a learning object with no files, only with metadata. Yes – SWORD is agnostic about what it deposits. It could deposit just file(s), just metadata, or both. Both versions of SWORD allow this. SWORD v2 is more specific in the specification about it, with the deposit of a basic Dublin Core record being given as an example: - http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_entry > 2. Using custom metadata for the deposit. Again, SWORD doesn't mind about what it deposits. As long as the SWORD client and server can both handle a custom metadata format, that is fine. Thanks, Stuart Lewis University of Edinburgh Stu...@ed...<mailto:Stu...@ed...><mailto:Stu...@ed...<mailto:Stu...@ed...>> -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Jonathan A. <jon...@gm...> - 2013-04-29 18:51:11
|
Hi Stuart, These features already are implemented in SWORD v1 php library, or should I implement following the sword specification? Is there any example of deposit with no files in sword v1 ? Thanks, Jonathan 2013/4/29 LEWIS Stuart <Stu...@ed...> > Hi Jonathan, > > I'll take a look at your service document and reply shortly. To answer > your other questions: > > > I have some other questions, in my dissertation I proposed some features > for the SWORD client: > > 1. Deposit a learning object with no files, only with metadata. > > Yes – SWORD is agnostic about what it deposits. It could deposit just > file(s), just metadata, or both. Both versions of SWORD allow this. SWORD > v2 is more specific in the specification about it, with the deposit of a > basic Dublin Core record being given as an example: > > - > http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_entry > > > 2. Using custom metadata for the deposit. > > Again, SWORD doesn't mind about what it deposits. As long as the SWORD > client and server can both handle a custom metadata format, that is fine. > > Thanks, > > > Stuart Lewis > University of Edinburgh > Stu...@ed...<mailto:Stu...@ed...> > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > |