July 2009 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-2639) Provide testcase for WS-Trust and WS-SecureConversation

by Alessio Soldano (JIRA)

Provide testcase for WS-Trust and WS-SecureConversation ------------------------------------------------------- Key: JBWS-2639 URL: https://jira.jboss.org/jira/browse/JBWS-2639 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-3.2.0 http://cwiki.apache.org/CXF20DOC/ws-trust.html http://cwiki.apache.org/CXF20DOC/ws-secureconversation.html -- 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

15 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-2708) XmlAttachmentRef annotation on List<DataHandler> is not identified as an Attachment part

by Magesh Kumar B (JIRA)

XmlAttachmentRef annotation on List<DataHandler> is not identified as an Attachment part ---------------------------------------------------------------------------------------- Key: JBWS-2708 URL: https://jira.jboss.org/jira/browse/JBWS-2708 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Reporter: Magesh Kumar B Assignee: Magesh Kumar B Consider a complex type <complexType name="ArrayOfSwaRefs"> <sequence> <element maxOccurs="unbounded" minOccurs="0" name="swaRef" nillable="true" type="wsi:swaRef"/> </sequence> </complexType> Using wsconsume the type is mapped to the class: @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "ArrayOfSwaRef", propOrder = { "swaRef" }) public class ArrayOfSwaRef { @XmlAttachmentRef protected List<DataHandler> swaRef; .... } Although if such a construct is allowed is debatable as API http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/XmlAttach... says that the filed/property must always map to a DataHandler class, jbossws-native misses to scan such parameter types properly and eventually the Content-Type is never set to multipart/related on the wire. -- 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

15 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBWS-2370) Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap

by Richard Opalka (JIRA)

Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap ------------------------------------------------------------------------------------------------------------ Key: JBWS-2370 URL: https://jira.jboss.org/jira/browse/JBWS-2370 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-metro, jbossws-native Affects Versions: jbossws-cxf-3.0.4, jbossws-metro-3.0.4, jbossws-native-3.0.4 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-3.0.5, jbossws-metro-3.0.5, jbossws-cxf-3.0.5 During deployment of the endpoints declared in my wars a call is made to AbstractServerConfig.getConnectorPort(). This fetches the WS Server MBean and tries to lookup objects of type "jboss.web:type=Connector,*". At the point where the lookup fails the jboss.web MBean has only one entry for the WebServer. In the run that I managed to debug the type=Connector entries were added at a later point. So, some of the subsequent calls to getConnectorPort() succeeded and also the AS bootstrap did not hang. I was unable to debug a case where the bootstrap did hang. -- 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

15 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2619) Consider DeploymentUnit's metadataLocation in ArchiveDeployment.getMetadataFileURL(..)

by Alessio Soldano (JIRA)

Consider DeploymentUnit's metadataLocation in ArchiveDeployment.getMetadataFileURL(..) -------------------------------------------------------------------------------------- Key: JBWS-2619 URL: https://jira.jboss.org/jira/browse/JBWS-2619 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Alessio Soldano Fix For: jbossws-native-3.2.0, jbossws-cxf-3.2.0, jbossws-metro-3.2.0 See: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154131 -- 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

15 years, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (JBWS-2675) Review maven dependencies

by Richard Opalka (JIRA)

Review maven dependencies ------------------------- Key: JBWS-2675 URL: https://jira.jboss.org/jira/browse/JBWS-2675 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-metro, jbossws-native Reporter: Richard Opalka We dropped AS 4.x support. Now our maven dependencies in all modules need review and ideally should refer only AS 5.x artifacts. This is required for better and proper AS integration, otherwise AS guys will need to define a lot of excludes. This includes: jbossws-spi jbossws-common jbossws-framework jbossws-native jbossws-metro jbossws-cxf -- 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

15 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-2707) Update to Apache CXF 2.2.3

by Alessio Soldano (JIRA)

Update to Apache CXF 2.2.3 -------------------------- Key: JBWS-2707 URL: https://jira.jboss.org/jira/browse/JBWS-2707 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-3.2.0 We need to update to Apache CXF 2.2.3 as soon as it's released. -- 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

15 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-2706) Unable to unmarshall attachment parts where the type is 'application/octet-stream'

by Darran Lofthouse (JIRA)

Unable to unmarshall attachment parts where the type is 'application/octet-stream' ---------------------------------------------------------------------------------- Key: JBWS-2706 URL: https://jira.jboss.org/jira/browse/JBWS-2706 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.0 Based on the following WSDL sections: - <message name="messageInput"> <part name="request" element="s:InputRequest"/> <part name="attach1" type="xsd:string"/> <part name="attach2" type="xsd:base64Binary"/> </message> <message name="messageOutput"> <part name="response" element="s:OutputResponse"/> <part name="attach1" type="xsd:string"/> <part name="attach2" type="xsd:base64Binary"/> </message> <binding name="SwaTestSoapBinding1" type="tns:SwaTest1"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <operation name="echoMultipleAttachments"> <soap:operation/> <input> <mime:multipartRelated> <mime:part> <soap:body parts="request" use="literal"/> </mime:part> <mime:part> <mime:content part="attach1" type="application/octet-stream"/> </mime:part> <mime:part> <mime:content part="attach2" type="application/octet-stream"/> </mime:part> </mime:multipartRelated> </input> <output> <mime:multipartRelated> <mime:part> <soap:body parts="response" use="literal"/> </mime:part> <mime:part> <mime:content part="attach1" type="application/octet-stream"/> </mime:part> <mime:part> <mime:content part="attach2" type="application/octet-stream"/> </mime:part> </mime:multipartRelated> </output> </operation> </binding> JBossWS can send messages without problem but unmarshalling the messages results in the following error: - Caused by: javax.xml.soap.SOAPException: javaType [[B] is not assignable from attachment content: java.io.ByteArrayInputStream at org.jboss.ws.core.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:248) The reason is because a DataHandler is used to wrap the attachment part, the data handler is passed the attachment along with the content type 'application/octet-stream' as this is not related to a specific type the call to getContent() on the DataHandler within EndpointInvocation returns an InputStraem for the attachment - this is not assignable to the expected Java type. The transformPayloadValue method in EndpointInvocation requires an additional step to take the InputStream and convert it to the expected Java type. -- 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

15 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-2521) Refactor / rewrite ServiceObjectFactory

by Alessio Soldano (JIRA)

Refactor / rewrite ServiceObjectFactory --------------------------------------- Key: JBWS-2521 URL: https://jira.jboss.org/jira/browse/JBWS-2521 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Fix For: jbossws-cxf-3.1.1 The jbossws-cxf ServiceObjectFactory needs to be cleaned: - Bus retrieval: this is currently performed through reflection on the Service class and following cast to cxf ServiceImpl; leveraging the BusFactory should be enough to get the default bus that is used by the cxf ProviderImpl for every Service creation - ServiceRef stub properties setup: this is currently performed through reflection on Service class to get the ServiceDelegate and then chaning the ServiceDelegate instance at runtime with a custom onesetting the properties. Instead of doing this hack, we should evaluate leveraging the CXF configuration for runtime constructed objects (http://cwiki.apache.org/CXF20DOC/configuration-of-runtime-constructed-obj...). IOW cxf ServiceImpl looks for a bean named portName.toString() + ".jaxws-client.proxyFactory" to configure the JaxWsProxyFactoryBean used to build the port and that factory bean allows for setting the stub properties. We might be able to generate on the fly and supply a bean configuration to the cxf bus for having our stub properties automatically configured by the already existing cxf configuration system. - perhaps even the handler chain configuration can be achieved in a way similar to the described in the previous point. -- 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

15 years, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (JBWS-2652) jboss-bootstrap upgrade

by Alessio Soldano (JIRA)

jboss-bootstrap upgrade ----------------------- Key: JBWS-2652 URL: https://jira.jboss.org/jira/browse/JBWS-2652 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-integration Affects Versions: jbossws-cxf-3.1.1, jbossws-metro-3.1.1, jbossws-native-3.1.1, jbossws-native-3.1.2 Reporter: Alessio Soldano Assignee: Alessio Soldano -- 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

15 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBWS-2705) Remove jbossws-native-jaxrpc.jar from endorsed dir

by Alessio Soldano (JIRA)

Remove jbossws-native-jaxrpc.jar from endorsed dir -------------------------------------------------- Key: JBWS-2705 URL: https://jira.jboss.org/jira/browse/JBWS-2705 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-3.2.0 The jbossws-native-jaxrpc.jar is currently installed in the endorsed dir lib along with the jaxws and saaj native jars. That's not strictly required (the reason for having the other libs there is to make sure jaxws native impl is loaded before the jdk ones when using jdk 1.6) and causes failures in the signaure module of JavaEE 5 TCK as the jaxrpc API refers to the Servlet API which of course is not in the endorsed dir. -- 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

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues July 2009