cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r887551 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs.html
Date Thu, 21 Nov 2013 15:48:14 GMT
Author: buildbot
Date: Thu Nov 21 15:48:13 2013
New Revision: 887551

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/jax-rs.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/jax-rs.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs.html (original)
+++ websites/production/cxf/content/docs/jax-rs.html Thu Nov 21 15:48:13 2013
@@ -185,21 +185,26 @@ public class MyStreamProvider implements
     }
     // other methods
 }
-{code:java} 
+]]></script>
+</div></div> 
 
-then the runtime will ignore it and choose a default InputStream/Reader reader because MyStreamProvider
is typed on Object. This was done to deal with the cases where well-known JSON/etc providers
are blindly supporting all types in their isReadable methods by always returning 'true' and
then failing when asked to actually read the incoming stream into InputStream/etc directly.
+<p>then the runtime will ignore it and choose a default InputStream/Reader reader because
MyStreamProvider is typed on Object. This was done to deal with the cases where well-known
JSON/etc providers are blindly supporting all types in their isReadable methods by always
returning 'true' and then failing when asked to actually read the incoming stream into InputStream/etc
directly. In case of MyStreamProvider, it will need to be split into MyInputStreamProvider
and MyReaderProvider typed on InputStream and Reader respectively.</p>
 
-At CXF level, the users which depend on CXF MultipartProvider to provider InputStream or
String references to multipart attachments will be affected unless they use @Multipart annotation.
For example, if we have a multipart payload with a single part/attachment only then the following
code:
+<p>At CXF level, the users which depend on CXF MultipartProvider to have InputStream
or String references to multipart attachments will be affected unless they use @Multipart
annotation. For example, if we have a multipart payload with a single part/attachment only
then the following code:</p>
 
-{code:java}
+<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
 @POST
 @Consumes("multipart/form-data")
 public void upload(InputStream is) {
 }
+]]></script>
+</div></div>
 
-which in CXF 2.7.x or earlier will return a pointer to first/single individual part, will
actually return a stream representing the complete unprocessed multipart payload. Adding a
@Multipart marker will keep the existing code working as expected:
+<p>which in CXF 2.7.x or earlier will return a pointer to first/single individual part,
will actually return a stream representing the complete unprocessed multipart payload. Adding
a @Multipart marker will keep the existing code working as expected:</p>
 
-{code:java}
+<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
 @POST
 @Consumes("multipart/form-data")
 public void upload(@Multipart InputStream is) {



Mime
View raw message