[JBoss JIRA] Created: (JBWS-3078) Fix the formatting for some of the java files
by Sergey Beryozkin (JIRA)
Fix the formatting for some of the java files
---------------------------------------------
Key: JBWS-3078
URL: https://jira.jboss.org/browse/JBWS-3078
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.0
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Trivial
Fix For: jbossws-cxf-4.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
- 2
- 1
[JBoss JIRA] Created: (JBWS-3074) @XmlMimeType break DataHandler
by Martin Vecera (JIRA)
@XmlMimeType break DataHandler
------------------------------
Key: JBWS-3074
URL: https://jira.jboss.org/browse/JBWS-3074
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.2.1
Reporter: Martin Vecera
Priority: Critical
I have a test client that sends WS attachment using DataHandler like this:
MTOMEndpoint mtomEndpoint = getEndpointPort();
DataHandler send = new DataHandler(new FileDataSource(PNG_FILE));
DHRequest request = new DHRequest(send);
DHResponse response = mtomEndpoint.echoData(request);
DataHandler recv = response.getDataHandler();
The server WS just sends back what it receives:
byte[] echoFile = StreamUtils.readStream((InputStream)(request.getDataHandler().getContent()));
DataHandler o = new DataHandler(new ByteArrayInputStream(echoFile), request.getDataHandler().getContentType());
return new DHResponse(o);
The issue is in DHRequest and DHResponse classes I use. They are simple classes:
@XmlType(name = "dataRequest", namespace = "http://org.jboss.ws/xop/doclit")
public class DHRequest {
private DataHandler dataHandler;
public DHRequest() { }
public DHRequest(DataHandler dataHandler) {
this.dataHandler = dataHandler;
}
// @XmlMimeType("image/png")
public DataHandler getDataHandler() {
System.out.println(dataHandler.getContentType());
return dataHandler;
}
public void setDataHandler(DataHandler dataHandler) {
this.dataHandler = dataHandler;
}
}
DHResponse is the same if you replace Reuest with Response.
Without setting the @XmlMimeType annotation everything works and the message on the server side looks like this:
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><ns2:echoDataResponse xmlns:ns2="http://org.jboss.ws/xop/doclit"><return><dataHandler> ... Base64 encoded data ... </dataHandler></return></ns2:echoDataResponse></env:Body></env:Envelope>
The DataHandler's content type on the client side (see the System.out.println) is image/png in the request and application/octet-stream in the response.
On the server side it is application/octet-stream in both cases.
No matter what I set in @XmlMimteType, it always broke. I tried application/octet-stream, text/plain and image/png. The thing is that whenever I set a mime type explicitly, the message stop being Base64 encoded. Instead it is a message with a binary attachment. The following is when DHResponse used application/octet-stream:
------=_Part_2_74198202.1277739135119
Content-Type: application/xop+xml; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart(a)ws.jboss.org>
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><ns2:echoDataResponse xmlns:ns2="http://org.jboss.ws/xop/doclit"><return><dataHandler><xop:Include xmlns:xop="http://www.w3.org/2004/0
8/xop/include" href="cid:dataHandler-75243ed1-23b7-4d2a-9ae6-aa2cb84c8e8f@ws.jboss.org"/></dataHandler></return></ns2:echoDataResponse></env:Body></env:Envelope>
------=_Part_2_74198202.1277739135119
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: <dataHandler-75243ed1-23b7-4d2a-9ae6-aa2cb84c8e8f(a)ws.jboss.org>
... binary scarp ...
------=_Part_2_74198202.1277739135119--
Attached is a sample ESB quickstart reproducing the issue. Please note that this is a regression in SOA-P. What is the expected behavior? How it should be used?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
- 3
- 6
[JBoss JIRA] Created: (JBWS-3076) Asynchronous WS-Security Client issues
by David Boeren (JIRA)
Asynchronous WS-Security Client issues
--------------------------------------
Key: JBWS-3076
URL: https://jira.jboss.org/browse/JBWS-3076
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.1.2
Reporter: David Boeren
Asynchronous WS-Security client (Callback and Polling) is failing when we invoke WS-Security endpoint but the Synchronous WS-Security client is working fine invoking the same endpoint. Here is the output on the client:
** Calling AsyncFoo w/no WSHeader
Exception In Client: This service requires <wsse:Security>, which is missing.
Client code and service are attached to the case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
- 1
- 0