Re: [sword-app-tech] depositMultipart always results in a 500 error

[Marco F. <mar...@ee...>]

Hi Hayden, Richard

I was in the same situation you are in a few weeks ago, although I was trying what you are trying to do using the python client.

Here is how I solved the problem:

- create an atom entry (which works for you), with the header in_progress = True

- add the file by posting to the "edit_media" url that I get in the deposit receipt from the previous entry creation. To do this, these are the headers I send:

filename="myfile.xxx" (this will get the name right in DSpace)
mimetype="application/zip"
packaging="http://purl.org/net/sword/package/Binary" (this will force the use of the Binary ingester, which is detecting the MIME type automatically).

I also slightly modified the BinaryIngester in DSpace because there was a small bug (which I reported). With these headers, and with "my" BinaryIngester, the file type is stored correctly. The only thing missing is the file's Description.

I created a simple command line tool to send files to DSpace, you can find it here: Project: SWORD Uploader
If you need the modified BinaryIngester, I can send you the compiled file (or the source if you prefer), if this could solve your problem.

Another way of depositing many files is to use the SimpleZip ingester: just zip all the files and post them with packaging="http://purl.org/net/sword/package/SimpleZip" . This will create an entry with a title defined by the name of the zip file. If you send the header in-progess=True, the entry will remain open. You can then update the metadata using the appropriate command.

Richard:
>As long as the mime type is in the "accept" list, then you should be
>able to use the correct mime type in the deposit (you could also set
>your accepts config option to */*.
 
I tried using */* but it didn't work for me, only specific MIME types worked.

Hope this help,
cheers
Marco

--------------------------------------------------
Marco Fabiani
Postdoctoral Research Assistant
Centre for Digital Music
School of Electronic Engineering and Computer Science
Queen Mary, University of London
Mile End Road, London E1 4NS, UK

On 30 Apr 2012, at 13:55, Hayden Young wrote:

> Hi Marco and Richard
> 
> Closer still to a solution I think.
> 
> Richard, I commented out the offending ingester: 
> 
> org.dspace.swordpackagers.SwordXifIngester = image/jpeg
> 
> unfortunately, this did not solve the problem but I now get the same error as if I attempt to ingest a PDF (I.e. file not found) so at least now there is some consistency. I checked all permissions on my upload.tempdir; as bitstreams are being successfully associated with items if I set the mimetype to "application/zip" I am guessing my directory permissions are correct?
> 
> Marco, thanks for the suggestion. I did set the mime type as application/zip and had some success with uploading the bitstreams; that is, the bitstream is appearing within the item). There are two issues:
> 
> 1. The file type is not detected and so it is given the file type "Unknown"
> 
> 2. No matter which type of file or how many files are uploaded, the first letter is always dropped from the file name. So, for example my_image.jpg will be renamed y_image.jpg or my_document.pdf will be y_document.pdf. I checked my mimetype settings and both image/jpeg and application/pdf are registered.
> 
> Therefore, I'm thinking could this be a swordv2 config issue? I have attached in case it assists with diagnosis.
> 
> Cheers
> 
> 
> Hayden
>