[JBoss JIRA] Created: (JBWS-1716) Erroneous UTF-8 character encoding when marshalling on machines with non-UTF-8 default encoding
by floe fliep (JIRA)
Erroneous UTF-8 character encoding when marshalling on machines with non-UTF-8 default encoding
-----------------------------------------------------------------------------------------------
Key: JBWS-1716
URL: http://jira.jboss.com/jira/browse/JBWS-1716
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-1.2.1
Reporter: floe fliep
When sending a client …
[View More]request which includes a non-ASCII UTF-8 character such as the "ç" in "Français" on a machine which has the default character encoding set to something different than UTF-8, the encoding is erroneous. For example, the "ç" in the example above is marshalled on the network stream as 0xC3 0x83 0xC2 0xA7 instead of the legal UTF-8 sequence being 0xC3 0xA7, when the machine's default character set is set to MS1252 in this case (Windows).
A fix for this is setting the system property file.encoding=utf-8, but this causes as many problems elsewhere as it fixes (especially in the case of legacy platform-specific file reading) ... .
A forum post is highly likely to expose the same phenomenon: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030510#4030510
After some good hours of stepping through the JBossWS code, I discovered what I guess must be the culprit in the method XMLFragment.writeSourceInternal(Writer writer):
....
if (reader == null)
reader = new InputStreamReader(streamSource.getInputStream());
Here streamSource.getInputStream() is an already UTF-8 encoded stream. However, when a new instance of InputStreamReader is created around it, it will be set to the machine's default character encoding, thus effectively interpreting bytes from the UTF-8 stream in a different encoding scheme, resulting in corrupted data.
Each time data passes through the marschalling corruption is added, effectively worsening wrong character count when data is passed back and forth.
I would suggest attaching a reader to the StreamSource source instance var so that it keeps track of its encoding, but that might break things elsewhere ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 8 months
[JBoss JIRA] Created: (JBWS-2640) UsernameToken does not correctly handle "Created" element from wsse:Security soap header
by MrTed MrTed (JIRA)
UsernameToken does not correctly handle "Created" element from wsse:Security soap header
----------------------------------------------------------------------------------------
Key: JBWS-2640
URL: https://jira.jboss.org/jira/browse/JBWS-2640
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ws-security
Affects Versions: jbossws-native-3.1.1
Environment: AS: …
[View More]jboss-4.2.3.GA on Windows XP
jbossws-native-3.1.1.GA
Reporter: MrTed MrTed
UsernameToken does not correctly handle "Created" element from wsse:Security soap header.
Oasis standard describes "Created" element in the following way:
/wsse:UsernameToken/wsu:Created
The optional <wsu:Created> element specifies a timestamp used to indicate the creation time. It is defined as part of the <wsu:Timestamp> definition.
The solution - Constants.WSU_NS should be used instead of Constants.WSSE_NS. "Created" element is described in http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utilit...
In the code org.jboss.ws.extensions.security.element.UsernameToken
"Created" element is recived via:
Iterator<Element> itCreated = DOMUtils.getChildElements(element, new QName(Constants.WSSE_NS, "Created"));
instead it should be:
Iterator<Element> itCreated = DOMUtils.getChildElements(element, new QName(Constants.WSU_NS, "Created"));
The same goes for line:
child = doc.createElementNS(Constants.WSSE_NS, Constants.WSSE_PREFIX + ":" + "Created");
should be:
child = doc.createElementNS(Constants.WSU_NS, Constants.WSU_PREFIX + ":" + "Created");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 11 months
[JBoss JIRA] Created: (JBWS-1672) SunRI does not respect @HandlerChain on client SEI
by Thomas Diesler (JIRA)
SunRI does not respect @HandlerChain on client SEI
--------------------------------------------------
Key: JBWS-1672
URL: http://jira.jboss.com/jira/browse/JBWS-1672
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: integration-sunri
Reporter: Thomas Diesler
Fix For: jbossws-2.1.0
tests-run-internal:
[junit] Running org.jboss.test.ws.jaxws.…
[View More]samples.handlerchain.HandlerChainTestCase
[junit] FIXME: [JBWS-1671] SunRI client handler cannot set mime header
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.209 sec
[junit] Test org.jboss.test.ws.jaxws.samples.handlerchain.HandlerChainTestCase FAILED
@WebService(name="Endpoint")
@SOAPBinding(style = SOAPBinding.Style.RPC)
@HandlerChain(file = "jaxws-handlers-client.xml") // relative path from the class file
public interface EndpointWithHandlerChain
{
public String echo(String input);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
15 years