March 2008 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-1439) Jdk 1.6.0 Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage"

by Denis Angleton (JIRA)

Jdk 1.6.0 Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage" -------------------------------------------------------------------------------------------------- Key: JBWS-1439 URL: http://jira.jboss.com/jira/browse/JBWS-1439 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-1.0.4 Environment: Jboss 4.0.5.GA Java 1.6.0 Reporter: Denis Angleton Requests get the error "setProperty must be overridden by all subclasses of SOAPMessage" In the abstract class javax.xml.soap.SOAPMessage which is now shipped with the jdk, the implementation of setProperty is as follows: public void setProperty(String property, Object value) throws SOAPException { throw new UnsupportedOperationException("setProperty must be overridden by all subclasses of SOAPMessage"); } in the constructor of org.jboss.ws.soap.SOAPMessageImpl it calls the super methods setProperty(CHARACTER_SET_ENCODING, "UTF-8"); setProperty(WRITE_XML_DECLARATION, false); This results in the exception being thrown. -- 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

12 years, 2 months

19
33
0 / 0

[JBoss JIRA] Created: (JBWS-1814) Dynamic Encryption based on clients input

by Magesh Kumar B (JIRA)

Dynamic Encryption based on clients input ----------------------------------------- Key: JBWS-1814 URL: http://jira.jboss.com/jira/browse/JBWS-1814 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-2.0.1, jbossws-1.2.1 Reporter: Magesh Kumar B Let's say that Bob runs the web service and Alice has a client that uses the web service. Now John would also like to use the web service. John would create: johns.keystore ---------------- john - keyPair (pub+priv) bob - trustedCertEntry (pub) johns.truststore ---------------- john - trustedCertEntry (just john's public key) In addition, Bob's keystore would be updated to: bobs.keystore ---------------- bob - keyPair (public + private key) alice - trustedCertEntry (just alice's public key) john - trustedCertEntry (just john's public key) This does not pose a problem for encrypting the request from the client side since both Alice and John use Bob's public key to encrypt the message, and Bob of course uses his pirvate key to decrypt the message. But how is the response message encrypted? JBossWS apparently does not support multiple clients because the certificate used by the server to encrypt the response is specified statically in jboss-wsse-server.xml. -- 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

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (JBWS-2070) Add attachment interop endpoint for MTOM and SwaRef

by Heiko Braun (JIRA)

Add attachment interop endpoint for MTOM and SwaRef --------------------------------------------------- Key: JBWS-2070 URL: http://jira.jboss.com/jira/browse/JBWS-2070 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Heiko Braun -- 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

12 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBWS-2068) Interop endpoints

by Heiko Braun (JIRA)

Interop endpoints ----------------- Key: JBWS-2068 URL: http://jira.jboss.com/jira/browse/JBWS-2068 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jbossws-3.0.2 Reporter: Heiko Braun Collection of interop related subtasks -- 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

12 years, 11 months

3
8
0 / 0

[JBoss JIRA] Created: (JBWS-2049) Provide a comprehensive test case for WS-RM

by Richard Opalka (JIRA)

Provide a comprehensive test case for WS-RM ------------------------------------------- Key: JBWS-2049 URL: http://jira.jboss.com/jira/browse/JBWS-2049 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Assigned To: Richard Opalka Fix For: jbossws-3.0.2 Supersedes JBWS-1700 -- 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

12 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-1949) MEtro MTOM ignores content-type on attachment part

by Heiko Braun (JIRA)

MEtro MTOM ignores content-type on attachment part -------------------------------------------------- Key: JBWS-1949 URL: http://jira.jboss.com/jira/browse/JBWS-1949 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: integration-metro Affects Versions: jbossws-2.0.3 Reporter: Heiko Braun Assigned To: Heiko Braun Fix For: jbossws-2.1.0 It turns everything into application/octet-stream on a DataHandler instance, even though the attachment part contains an explicit content-type. -- 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

14 years, 3 months

4
17
0 / 0

[JBoss JIRA] Created: (JBWS-1671) SunRI client handler cannot set mime header

by Thomas Diesler (JIRA)

SunRI client handler cannot set mime header ------------------------------------------- Key: JBWS-1671 URL: http://jira.jboss.com/jira/browse/JBWS-1671 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 [tdiesler@tddell sunri]$ ant -Dtest=jaxws/samples/handlerchain test tests-run-internal: [junit] Running org.jboss.test.ws.jaxws.samples.handlerchain.HandlerChainTestCase [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.162 sec [junit] Test org.jboss.test.ws.jaxws.samples.handlerchain.HandlerChainTestCase FAILED Caused by: java.lang.IllegalStateException: Unexpected cookie list: null at org.jboss.test.ws.jaxws.samples.handlerchain.ClientMimeHandler.handleInbound(ClientMimeHandler.java:64) at org.jboss.wsf.spi.handler.GenericHandler.handleMessage(GenericHandler.java:55) at com.sun.xml.ws.handler.HandlerProcessor.callHandleMessageReverse(HandlerProcessor.java:313) at com.sun.xml.ws.handler.HandlerProcessor.callHandlersResponse(HandlerProcessor.java:195) at com.sun.xml.ws.handler.ClientSOAPHandlerTube.callHandlersOnResponse(ClientSOAPHandlerTube.java:181) -- 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

14 years, 3 months

3
13
0 / 0

[JBoss JIRA] Created: (JBWS-1777) WSProvide output is not correctly redirected

by Heiko Braun (JIRA)

WSProvide output is not correctly redirected -------------------------------------------- Key: JBWS-1777 URL: http://jira.jboss.com/jira/browse/JBWS-1777 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Heiko Braun Assigned To: Heiko Braun See WSProvideTestCase -- 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

14 years, 3 months

4
18
0 / 0

[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 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

14 years, 5 months

4
8
0 / 0

[JBoss JIRA] Created: (JBWS-1763) Specified charset type not used when parsing request

by Darran Lofthouse (JIRA)

Specified charset type not used when parsing request ---------------------------------------------------- Key: JBWS-1763 URL: http://jira.jboss.com/jira/browse/JBWS-1763 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-1.2.0.SP1 Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: jbossws-2.0.1 Specified charset type not used when parsing request message. -- 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

14 years, 6 months

3
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues March 2008