June 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3651) Reduce need for explicit dependency on org.apache.ws.security module

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3651: ------------------------------------- Summary: Reduce need for explicit dependency on org.apache.ws.security module Key: JBWS-3651 URL: https://issues.jboss.org/browse/JBWS-3651 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Assignee: Alessio … [View More]

11 years, 9 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/4642 > Unlock FastInfoset feature in CXF on top of JBossAS > --------------------------------------------------- > > Key: JBWS-3560 > URL: https://issues.jboss.org/browse/JBWS-3560 > Project: JBoss Web Services > … [View More]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements and tooling

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3648: ---------------------------------- Fix Version/s: jbossws-cxf-4.2 (was: jbossws-cxf-4.3) > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services &… [View More]gt; Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required. > An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set). > With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config). > The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones). > Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc. > [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-... -- 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 [View Less]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3650) CXF XSD resolution is not working

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3650?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3650: ---------------------------------- Priority: Major (was: Blocker) > CXF XSD resolution is not working > --------------------------------- > > Key: JBWS-3650 > URL: https://issues.jboss.org/browse/JBWS-3650 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone … [View More]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3650) CXF XSD resolution is not working

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3650?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3650: ---------------------------------- Fix Version/s: jbossws-cxf-4.2 > CXF XSD resolution is not working > --------------------------------- > > Key: JBWS-3650 > URL: https://issues.jboss.org/browse/JBWS-3650 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone … [View More]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3650) CXF XSD resolution is not working

by Xavier Dury (JIRA)

Xavier Dury created JBWS-3650: --------------------------------- Summary: CXF XSD resolution is not working Key: JBWS-3650 URL: https://issues.jboss.org/browse/JBWS-3650 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Environment: JBoss EAP 6.1 Reporter: Xavier Dury Priority: Blocker When configuring WS endpoints … [View More]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native

by A l e c C R E S T A N (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] A l e c C R E S T A N edited comment on JBWS-3593 at 6/12/13 9:47 AM: ---------------------------------------------------------------------- Hi, no, the @XmlMimeType("text/xml") annotation does not change the result. Result is still "xop"... {code:title=Response|borderStyle=solid} Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:13fed152-2261-4a2a-90a5-b20f185e2e22"; start="<root.… [View More]message(a)cxf.apache.org>"; start-info="text/xml" --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"; Content-Transfer-Encoding: binary Content-ID: <root.message(a)cxf.apache.org> <soap:Envelope ...</soap:Envelope> --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22-- {code} was (Author: jbossalecuser): Hi, no, the @XmlMimeType("text/xml") annotation does not change the result. Result is still "xop"... {code:title=Bar.java|borderStyle=solid} Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:13fed152-2261-4a2a-90a5-b20f185e2e22"; start="<root.message(a)cxf.apache.org>"; start-info="text/xml" --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"; Content-Transfer-Encoding: binary Content-ID: <root.message(a)cxf.apache.org> <soap:Envelope ...</soap:Envelope> --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22-- {code} > @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native > -------------------------------------------------------------------------------------------------------------------- > > 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 > 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 [View Less]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3593) @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native

by A l e c C R E S T A N (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] A l e c C R E S T A N commented on JBWS-3593: --------------------------------------------- Hi, no, the @XmlMimeType("text/xml") annotation does not change the result. Result is still "xop"... {code:title=Bar.java|borderStyle=solid} Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:13fed152-2261-4a2a-90a5-b20f185e2e22"; start="<root.message(a)cxf.apache.org>"; start-info="text/… [View More]xml" --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"; Content-Transfer-Encoding: binary Content-ID: <root.message(a)cxf.apache.org> <soap:Envelope ...</soap:Envelope> --uuid:13fed152-2261-4a2a-90a5-b20f185e2e22-- {code} > @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native > -------------------------------------------------------------------------------------------------------------------- > > 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 > 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 [View Less]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3571) SOAPAddressWSDLParser does not process wsdl imports

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3571?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3571: ----------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 916944|https://bugzilla.redhat.com/show_bug.cgi?id=916944] from ASSIGNED to CLOSED > SOAPAddressWSDLParser does not process wsdl imports > --------------------------------------------------- > > Key: JBWS-… [View More]

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3571) SOAPAddressWSDLParser does not process wsdl imports

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3571?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3571: ----------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> made a comment on [bug 916944|https://bugzilla.redhat.com/show_bug.cgi?id=916944] Customer case is closed. I'm closing this as WON'T FIX. > SOAPAddressWSDLParser does not process wsdl imports > --------------------------------------------------- > … [View More]

11 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues June 2013