[
https://issues.apache.org/jira/browse/STANBOL-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201322#comment-13201322
]
Rupert Westenthaler edited comment on STANBOL-481 at 2/7/12 1:29 PM:
---------------------------------------------------------------------
The current plan is to implement ContentItemWriter and ContentItemReader as
MessageBodyWriter/Reader. This will allow a nice integration of ContentItem
with JAX-RS resource.
This also means the the defualt Multipart MIME functionality of Jersey will NOT
be used for ContentItems.
### Serialization:
I have implemented a prototype using the "org.apache.httpcomponents.httpmime"
framework. This looks really great, because it natively supports "streaming".
This has the big advantage (in contrast to the javax.mail) that there will be
no issues even if the ContentItem refers to very big content items.
The dependencies are:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
### Parsing
For parsing I have a working prototype that uses the
"FileUpload.getItemIterator(..)". This is also a streaming based solution and
works without any data to be written to the disc of kept in memory. See also
[1].
The dependencies are:
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>
Details about the used Multipart MIME format for content Items see the next
comment.
[1] http://commons.apache.org/fileupload/streaming.html
was (Author: rwesten):
Short Update:
I have written a small prototype using
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
I do like this API much more than javax.mail, because it allows easily to
"stream" all the data directly to the OutputStream!
that produces for the ContentItem
uri: urn:test
content type : text/html
contentPart:
uri: urn:test:text
content type : text/plain
metadata:
urn:test, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, urn:types:Document
the following Multipart Mime:
--OHPnQAMLYDkzNWjtO3eHRL_Gmkj3msRmPDuY
Content-Disposition: form-data; name="metadata"; filename="metadata"
Content-Type: application/rdf+xml; charset=UTF-8
Content-Transfer-Encoding: 7bit
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:j.0="urn:types:" >
<rdf:Description rdf:about="urn:test">
<rdf:type rdf:resource="urn:types:Document"/>
</rdf:Description>
</rdf:RDF>
--OHPnQAMLYDkzNWjtO3eHRL_Gmkj3msRmPDuY
Content-Disposition: form-data; name="content"
Content-Type: multipart/alternate; charset=UTF-8
Content-Transfer-Encoding: 7bit
--contentParts
Content-Disposition: form-data; name="urn:test_main"
Content-Type: text/html
Content-Transfer-Encoding: binary
<html><body>Test</body></html>
--contentParts
Content-Disposition: form-data; name="run:text:text"
Content-Type: text/plain
Content-Transfer-Encoding: binary
test
--contentParts--
--OHPnQAMLYDkzNWjtO3eHRL_Gmkj3msRmPDuY--
This should be in conformance with the specification
> Multi ContentPart RESTful API extensions
> ----------------------------------------
>
> Key: STANBOL-481
> URL: https://issues.apache.org/jira/browse/STANBOL-481
> Project: Stanbol
> Issue Type: Sub-task
> Components: Enhancer
> Reporter: Rupert Westenthaler
> Assignee: Rupert Westenthaler
> Attachments: contentItemAsMultipartMime.txt
>
>
> Sub-task about the implementation of the RESTful API extensions related to
> multipart content items
> Copied form the main Issue:
> - query params:
> Optional inputWithMetadata -> expects multipart/mime with 2 sections of which
> the first is rdf
> Optional outputWithContentParts[=<section-ordinal>] -> the result is
> multipart (instead of rdf) containing rdf as the first section and the parts
> in the second section, if there is more than one part this second section is
> itself multipart, this argument might be repated to have different sections
> Optional omitMetada -> no metadate in the result, makes only sense with
> outputContentParts argument, the result will correspond to the second section
> of the malipart returned without this argument
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
