You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by "Peter Masters (JIRA)" <ji...@apache.org> on 2012/10/31 15:47:12 UTC
[jira] [Created] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Peter Masters created WINK-371:
----------------------------------
Summary: Data conversion issue for Multi-part MIME on mainframe (z/OS)
Key: WINK-371
URL: https://issues.apache.org/jira/browse/WINK-371
Project: Wink
Issue Type: Bug
Components: Server
Affects Versions: 1.2
Environment: z/OS primarily
Reporter: Peter Masters
We have a method annotated as follows:-
@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Produces(MediaType.TEXT_XML)
When we look through the parts on zOS, using:
while (iterator.hasNext()) {
InPart part = iterator.next();
InputStream is = part.getBody(InputStream.class, null);
...
}
we see an exception
java.lang.StringIndexOutOfBoundsException
at java.lang.String.substring(String.java:1092)
at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
...
The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496017#comment-13496017 ]
Luciano Resende commented on WINK-371:
--------------------------------------
I have made the change as suggested :
diff --git a/wink-common/src/main/java/org/apache/wink/common/internal/providers/multipart/MultiPartParser.java b/wink-common/src/main/java/org/apache/wink/common/internal/providers/multipart/MultiPar
index 1126a30..bc76772 100644
--- a/wink-common/src/main/java/org/apache/wink/common/internal/providers/multipart/MultiPartParser.java
+++ b/wink-common/src/main/java/org/apache/wink/common/internal/providers/multipart/MultiPartParser.java
@@ -36,6 +36,7 @@ import org.apache.wink.common.internal.i18n.Messages;
public class MultiPartParser {
public final static String SEP = "\n"; //$NON-NLS-1$
+ public final static String UTF8 = "UTF-8"; //$NON-NLS-1$
private InputStream is;
private byte[] boundaryBA;
@@ -297,7 +298,7 @@ public class MultiPartParser {
return null;
}
- String hdr = new String(buff, buffIdx, lineIdx);
+ String hdr = new String(buff, buffIdx, lineIdx, UTF8);
buffIdx += lineIdx + breakeSize;
return hdr;
}
And will attach a patched jar. Could you help verify that it fixes the problem.
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luciano Resende updated WINK-371:
---------------------------------
Attachment: MultiPartParser.class
As you had to do some surgery on the previous jar, here is just a compiled class with some changes to better handle encoding and also some system.out around the place where we are seeing the error. Could you please give it a try and provide the messages being printed.
Thanks
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: MultiPartParser.class, wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Georg Sander (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495216#comment-13495216 ]
Georg Sander commented on WINK-371:
-----------------------------------
I think the analysis by the submitter is correct. Wink converts byte[] to String via new String(byte[], int, int), not taking any charset into account. Therefore it uses the platform encoding. This is wrong, since the header comes from a client, not from the server platform. We run into a similar issue (not the exception, but garbled strings) on Windows 7 and on Linux by explicitly setting the platform encoding to US-ASCII.
Wink should use new String(byte[], int, int, charset) instead. The issue is related to https://issues.apache.org/jira/browse/COCOON-858 where it is fixed in newer versions. Wink seems to use the same parser for multi part headers, but the fix did not make it yet into Wink 1.2.
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Peter Masters (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496057#comment-13496057 ]
Peter Masters commented on WINK-371:
------------------------------------
Hi - many thanks for the response. I will give the patch a go and see if this has fixed the problem.
Cheers, Peter
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Peter Masters (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498950#comment-13498950 ]
Peter Masters commented on WINK-371:
------------------------------------
Hi Luciano - we're using Wink 1.2 - thanks for the fast response :)
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Anton Piatek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498753#comment-13498753 ]
Anton Piatek commented on WINK-371:
-----------------------------------
Hi, I work with Pete and have been trying to veryfiy your fix.
Initially I unpacked your supplied jar and updated my wink 1.2 jar with the classes you provided. This unfortunately broke the json marshaller, presumably due to a change between 1.2 and 1.3.
Then I tried to update just a few class files to see if that would fix it.
I took my clean wink 1.2 jar and updated it with the following class files from your supplied jar:
./org/apache/wink/common/internal/providers/multipart/MultiPartParser$PartInputStream.class
./org/apache/wink/common/internal/providers/multipart/MultiPartParser.class
my
This did no break the json marshaller, but it appears not to have fixed the issue - the following error is still seen:
java.lang.StringIndexOutOfBoundsException</cause><stackTrace>java.lang.String.substring(String.java:1092)
org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:265)
org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:110)
org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
It is unfortunate that our legal department has prohibited us from looking at the wink source code.
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Anton Piatek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510444#comment-13510444 ]
Anton Piatek commented on WINK-371:
-----------------------------------
unfortunately I still get the same error:
java.lang.StringIndexOutOfBoundsException</cause><stackTrace>java.lang.String.substring(String.java:1092)
org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
I think your stdouts were captured in our debug trace, however I don't think they are going to help much as they seem to be coming out in the wrong codepage:
2012-12-05 11:52:35.353092 43 org.apache.wink.server.internal.log.LogUtilities.logResourceMetadata 'MbJavaUtilLogHandler:FINEST' , 'Resource information for com.ibm.broker.
admin.requestHandlers.UploadedResourceHandler:
Path HTTP Method Consumes Produces Resource Method
workspace/uploadedResource GET [*/*] [application/json] com.ibm.broker.admin.requestHandlers.Uplo
adedResourceHandler.getResources(Request)
workspace/uploadedResource/{browserType}/upload/{mainResource}/commit POST [*/*] [application/json] com.ibm.broker.admin.requestHandlers.Uplo
adedResourceHandler.commitUploadedResource(Request,String,String)
workspace/uploadedResource/uploadedWSDLs/{resourceName} DELETE [*/*] [application/json] com.ibm.broker.admin.requestHandlers.Uplo
adedResourceHandler.deleteWSDL(String,Request)
workspace/uploadedResource/{browserType}/upload/{mainResource} POST [multipart/form-data] [text/html] com.ibm.broker.admin.requestHandlers.Upl
oadedResourceHandler.uploadDependentResource(Request,InMultiPart,String,String)
workspace/uploadedResource/uploadedWSDLs/{resourceName} DELETE [*/*] [application/json] com.ibm.broker.admin.requestHandlers.Uplo
adedResourceHandler.deleteWSDL(String,Request)
workspace/uploadedResource/{browserType}/upload/{mainResource} POST [multipart/form-data] [text/html] com.ibm.broker.admin.requestHandlers.Upl
oadedResourceHandler.uploadDependentResource(Request,InMultiPart,String,String)
workspace/uploadedResource/{browserType}/upload POST [multipart/form-data] [text/html] com.ibm.broker.admin.requestHandlers.Upl
oadedResourceHandler.uploadResource(Request,InMultiPart,String)
workspace/uploadedResource/{type} GET [*/*] [application/json] com.ibm.broker.admin.requestHandlers.Uplo
adedResourceHandler.getResourcesForType(String,Request)'
2012-12-05 11:52:35.356592 43 org.apache.wink.server.internal.log.ResourceInvocation.logFinishRequest 'MbJavaUtilLogHandler:FINE' , 'Resource invocation:
-> com.ibm.broker.admin.requestHandlers.UploadedResourceHandler.uploadResource(Request,InMultiPart,String)'
2012-12-05 11:52:35.358252 43 org.apache.wink.server.internal.log.Requests.logFinishRequest 'MbJavaUtilLogHandler:FINEST' , 'logFinishRequest() entry'
2012-12-05 11:52:35.359728 43 org.apache.wink.server.internal.log.Requests.logFinishRequest 'MbJavaUtilLogHandler:FINE' , 'The request entity as a String in the default enc
oding:'
2012-12-05 11:52:35.361288 43 org.apache.wink.server.internal.log.Requests.logFinishRequest 'MbJavaUtilLogHandler:FINE' , '^A000000000000000000000000^B^57^65^62.^69^74^46?^
72_^42?^75>^64/^72`^71^39|^63^34^64^48^42(^51%^39^52^58^33^43
^0A^43?>^74^65>^74^A0000^B^44^69^73^70?^73^69^74^69?>^3A^20^66?^72_^A0000^B^64/^74/^3B^20>/_^65^A0000^B^22^75^70%?/^64^65^64^66^69%^65^73$)^22^3B^20^66^69%^65>/_^65^A0000^B^22^77
^0A^43?>^74^65>^74^A0000^B^54`^70^65^3A^20/^70^70%^69^63/^74^69?>^A0000^B?^63^74^65^74^A0000^B^73^74^72^65/_
......
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: MultiPartParser.class, wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498903#comment-13498903 ]
Luciano Resende commented on WINK-371:
--------------------------------------
Could you clarify what version you are using ? Wink 1.1.2 or Wink 1.2 ? Then I can produce the correct patch.
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WINK-371) Data conversion issue for Multi-part
MIME on mainframe (z/OS)
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luciano Resende updated WINK-371:
---------------------------------
Attachment: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
Patched jar for verifying this fix. Should work ok on top of wink-1.2.x
> Data conversion issue for Multi-part MIME on mainframe (z/OS)
> -------------------------------------------------------------
>
> Key: WINK-371
> URL: https://issues.apache.org/jira/browse/WINK-371
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.2
> Environment: z/OS primarily
> Reporter: Peter Masters
> Attachments: wink-common-1.3.0-incubating-SNAPSHOT-with-wink371-fix.jar
>
>
> We have a method annotated as follows:-
> @POST
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Produces(MediaType.TEXT_XML)
> When we look through the parts on zOS, using:
> while (iterator.hasNext()) {
> InPart part = iterator.next();
> InputStream is = part.getBody(InputStream.class, null);
> ...
> }
> we see an exception
> java.lang.StringIndexOutOfBoundsException
> at java.lang.String.substring(String.java:1092)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.parseHeaders(MultiPartParser.java:264)
> at org.apache.wink.common.internal.providers.multipart.MultiPartParser.nextPart(MultiPartParser.java:109)
> at org.apache.wink.common.model.multipart.InMultiPart.hasNext(InMultiPart.java:83)
> ...
> The headers going over the wire are in UTF-8, but I believe Wink is trying to decode them as platform encoding (e.g. a new String(bytes), without a codepage specified). On a regular windows/linux box this would work for normal codepoints, but on zOS, EBCDIC encoding is nothing like UTF-8, so the assumption wouldn't work. I'm unfortunately not permitted to look at wink sourcecode (legal reasons) so I cannot verify this myself, but as this is a string handling error on a UTF-8 string, that is the best guess I can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira