June 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3396) Partial generation of jbossws-cxf.xml descriptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3396?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3396: ---------------------------------- Summary: Partial generation of jbossws-cxf.xml descriptor (was: Evaluate partial generation of jbossws-cxf.xml descriptor) > Partial generation of jbossws-cxf.xml descriptor > ------------------------------------------------ > > Key: JBWS-3396 > URL: https://issues.jboss.org/browse/JBWS-3396 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > > See http://community.jboss.org/message/640779#640779 . Basically the issue with the need for user to specify every endpoint in the jbossws-cxf.xml, while in some case the info might come from the metadata created from the web.xml / annotations. At least we could have defaults. > The same applies to defaults for the address attribute in jaxws:endpoint. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3653) soap:address of generated WSDLs never uses the wsdl-host defined in webservices subsystem

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3653: ------------------------------------- Summary: soap:address of generated WSDLs never uses the wsdl-host defined in webservices subsystem Key: JBWS-3653 URL: https://issues.jboss.org/browse/JBWS-3653 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Affects Versions: jbossws-cxf-4.1.1 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.2 The code-first development approach was not properly considered when working on JBWS-3570. As a consequence, the Apache CXF automatic address rewrite is always on if there's no user provided wsdl. That does not allow setting a load balancer address into the published wsdl when the corresponding endpoint is a code-first one. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3593: ---------------------------------- Fix Version/s: (was: jbossws-cxf-4.2) > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3593: --------------------------------------- I did some investigation on this issue; basically, what happens is that if the MTOM enabled endpoint has multiple operations, responses for any of them end up into multipart/related messages regardless of an attachment being actually present or not. Please note the messages (including the content type values) are still valid, it's just that the message is a multipart one (actually with just a single part if there's no attachment). This behaviour is basically a consequence of the the @MTOM / @BindingType annotations being type level ones and of the way Apache CXF integrates with JAXB (see org.apache.cxf.jaxb.io.DataWriterImpl and org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller). To me the only way to change this would be for Apache CXF to have a mechanism for automatically detecting if a given message response would contain an attachment, so that the mtom-enabled prop could be set to false in the current cxf Message. That would likely imply scanning the generated java model for the endpoint and looking for @XmlMimeType annotations or similar approach. XFIRE (which predates CXF) had a feature request jira for this need, see http://jira.codehaus.org/browse/XFIRE-664, user might consider creating a new CXF jira for this (it's an addition / new feature though, not really a bug). As a temporary measure / workaround, the user can add a simple out interceptor to his endpoint, which can explicitly disable MTOM depending on the selected operation. I've added a testcase to the JBossWS testsuite to demonstrate this [1][2]. The interceptor is here [3]. [1] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/... [2] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/... (search '3593') [3] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/... > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3593: ---------------------------------- Summary: multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included (was: @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native) > multipart/related messages exchanged for @MTOM annotated endpoint even if no attachment is included > --------------------------------------------------------------------------------------------------- > > Key: JBWS-3593 > URL: https://issues.jboss.org/browse/JBWS-3593 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-native > Affects Versions: jbossws-cxf-4.0.2, jbossws-native-4.0.2 > Environment: Jboss AS 7.1.1Final > Reporter: A l e c C R E S T A N > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > On JBoss AS 7.1.1, with the following service implementation: > {code} > @WebService(...) > @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING) > public class SEIImpl { > ... > public DataHandler getBin() {...} /* maps to a type="xs:base64Binary" in wsdl */ > public List<String> getString(){...} /* maps to sequence of String in wsdl */ > ... > } > {code} > With the default *jbossws-cxf*, the responses are: > - for getString() method > Content-Type: multipart/related; type="application/xop+xml"; ... > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > -> +both responses are MTOM/XOP modified ! The getString() response should not.+ > With *jbossws-native* (after the jbossws stack switching) , the responses are the expected ones: > - for getString() method > Content-Type: text/xml;charset=UTF-8 <env:Envelope .... text content ..../env:Envelope> > - for getBin() method > Content-Type: multipart/related; type="application/xop+xml"; ... > Best regards, > Note: same behaviour with @javax.xml.ws.soap.MTOM or SOAP11HTTP_MTOM_BINDING -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-1939) URL port information of soap:address is different from import schemaLocation URL

by Vishnu Prakash (JIRA)

[ https://issues.jboss.org/browse/JBWS-1939?page=com.atlassian.jira.plugin.... ] Vishnu Prakash commented on JBWS-1939: -------------------------------------- Sorry to comment on a closed post. But what is the path of jboss-beans.xml in JBoss 7? Facing the same issue as in description. > URL port information of soap:address is different from import schemaLocation URL > -------------------------------------------------------------------------------- > > Key: JBWS-1939 > URL: https://issues.jboss.org/browse/JBWS-1939 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-native > Affects Versions: jbossws-2.0.0 > Environment: SunOS serrano 5.8 Generic_108528-18 sun4u sparc SUNW,Ultra-60 > Reporter: Suresh Srinivas > Assignee: Richard Opalka > Fix For: jbossws-native-2.0.3 > > > Setup info 1: > The setup has in deploy/jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml the following lines commented: > <property name="webServiceHost">${jboss.bind.address}</property> > <property name="webServicePort">8080</property> > This should result in the protocol, port and the host being picked up from requesters URL. > Setup info 2: > I have JBoss server setup behind apache server. Apache web server forwards request to the JBoss Server using mod_jk. The host ip for the apache server is 38.187.114.136. The host ip for the JBoss server is 38.187.114.238. The JBoss web services are bound to port 8180. > Observer behavior: > When I access the WSDL using http:/38.187.114.136/application/SessionService?wsdl the WSDL I received has the following information: > <definitions name="InitMethod" targetNamespace="http://com.foo.service/callcontrol"> > <types> > <xsd:schema> > <xsd:import namespace="http://com.foo.service/callcontrol/types" schemaLocation="http://38.187.114.136/service/SessionService?wsdl&resource=Session.xsd"/> > </xsd:schema> > ..... > ..... > ..... > <port binding="ns2:SessionServiceBinding" name="SessionServicePort"> > <soap:address location="http://38.187.114.136:8180/service/SessionService"/> > </port> > </service> > </definitions> > Problem description: > - schemaLocation is right. It is using requesters protocol, port and host "http://38.187.114.136/service/SessionService?wsdl&resource=Session.xsd" > - soap:address location does not match schemaLocation. It does not use the port corresponding to the request and instead provides port where the service is running - "http://38.187.114.136:8180/service/SessionService" -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3620) Authentication failures w/ Undertow

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3620?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3620: ---------------------------------- Fix Version/s: jbossws-cxf-4.3 (was: jbossws-cxf-4.2) > Authentication failures w/ Undertow > ----------------------------------- > > Key: JBWS-3620 > URL: https://issues.jboss.org/browse/JBWS-3620 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3 > > > As a consequence of AS8 having moved to use Undertow, we have some failures on authentication. Need to investigate further. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3652) AbstractServerConfig.toIPv6URLFormat shoule not add brackets to IPv6 hostname

by Dillon Liang (JIRA)

Dillon Liang created JBWS-3652: ---------------------------------- Summary: AbstractServerConfig.toIPv6URLFormat shoule not add brackets to IPv6 hostname Key: JBWS-3652 URL: https://issues.jboss.org/browse/JBWS-3652 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Dillon Liang I am trying to specify the wsdl-host in AS7 webservice subsystem under IPv6 environment. I found if I provide the hostname, the web service will have wrong URL which has the brackets. This can be found in server.log. The correct way to fix it is to determine whether the host parameter is a hostname or a pure IP address. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3560) Unlock FastInfoset feature in CXF on top of JBossAS

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3560?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3560: --------------------------------------- https://github.com/wildfly/wildfly/pull/4658 > Unlock FastInfoset feature in CXF on top of JBossAS > --------------------------------------------------- > > Key: JBWS-3560 > URL: https://issues.jboss.org/browse/JBWS-3560 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Richard Opalka > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3560) Unlock FastInfoset feature in CXF on top of JBossAS

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3560?page=com.atlassian.jira.plugin.... ] Alessio Soldano reopened JBWS-3560: ----------------------------------- Looks like the new module in WFLY is missing some dependencies... > Unlock FastInfoset feature in CXF on top of JBossAS > --------------------------------------------------- > > Key: JBWS-3560 > URL: https://issues.jboss.org/browse/JBWS-3560 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Richard Opalka > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > -- 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

10 years, 10 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 June 2013