June 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3601) SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3601?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3601: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> made a comment on [bug 913411|https://bugzilla.redhat.com/show_bug.cgi?id=913411] Was proposed or approved for 6.1.0 but did not make it into the payload, so setting jboss-eap-6.1.0- (for history) and jboss-eap-6.1.1? (to try again) > SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF > -------------------------------------------------------------- > > Key: JBWS-3601 > URL: https://issues.jboss.org/browse/JBWS-3601 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.0.2 > Environment: JBoss Enterprise Application Platform 6 > Reporter: Tadayoshi Sato > Assignee: Alessio Soldano > Labels: cxf > Fix For: jbossws-cxf-4.2 > > > Backport https://issues.apache.org/jira/browse/CXF-4790, which is the root cause. The code below doesn't render {{<soapenv:Subcode>}}. > {code} > import javax.xml.soap.SOAPConstants; > import javax.xml.soap.SOAPFactory; > import javax.xml.soap.SOAPFault; > import javax.xml.ws.soap.SOAPFaultException; > ... > SOAPFactory factory = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL); > SOAPFault fault = factory.createFault("Operator not found", new QName(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE, "Receiver")); > fault.appendFaultSubcode(new QName("...", "OperatorNotFound")); > ... > throw new SOAPFaultException(fault); > {code} -- 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-3649) Invoke LifecycleHandler in EndpointService

by Jim Ma (JIRA)

Jim Ma created JBWS-3649: ---------------------------- Summary: Invoke LifecycleHandler in EndpointService Key: JBWS-3649 URL: https://issues.jboss.org/browse/JBWS-3649 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.1.3 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.2 LifecycleHandler is now called in EndpointServiceDeploymentAspect , which can not get the EndpointService state. If EndpointService is failed , the LifeCycleHandler is still called and set the Endpoint state to started. Invoke the LifeCycleHandler in EndpointService is better to sync the Endpoint state with EndpointService's state. -- 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-3610) Review of AccessController and PrivilegedAction use across JBossWS

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3610?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3610: ---------------------------------- Fix Version/s: jbossws-cxf-4.3 (was: jbossws-cxf-4.2) > Review of AccessController and PrivilegedAction use across JBossWS > ------------------------------------------------------------------ > > Key: JBWS-3610 > URL: https://issues.jboss.org/browse/JBWS-3610 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3 > > > See https://issues.jboss.org/browse/AS7-6316 description; most of that (especially on use of singletons for no param privileged actions) needs to be done on JBossWS codebase too. -- 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) @javax.xml.ws.BindingType or @javax.xml.ws.soap.MTOM have a different behaviour with jbossws-cxf than jbossws-native

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3593?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3593: --------------------------------------- Is adding a @XmlMimeType annotation to the getString() method a valid approach for getting the same behavior as before? > @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

10 years, 10 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 commented on JBWS-3648: --------------------------------------- Thanks for the feedback Jim. Yes, the normalize and merge might not be needed, I noticed that after creating the jira, but will likely have a deeper look later. Regarding the tooling section of this jira and CXF, I think this could be re-evaluated later, after the changes that are coming in CXF 3.0; afair on the mailing list, there's an ongoing effort for having new tooling options to generate cxf specific code, etc. > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3 > > > 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

10 years, 10 months

1
0
0 / 0

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

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3648: ------------------------------ I like this idea. It will help user configure the ws policy more easily : configure the policy with EndpointConfig name and the uri to refer the policy name, and no need to touch with the policy xml element. Regarding the customized PolicyAnnotationListener, we probably do not need to do extra step to normalize and merge polices and policy interceptor will handle it. Do not know if it is still the same thing in CXF. IMO the tooling improvement is even an interesting feature in CXF. How about we move this to CXF in the future and enhance this feature in CXF's java2ws, it will be much easier. Your thoughts? > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Fix For: jbossws-cxf-4.3 > > > 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3378: ---------------------------------- Fix Version/s: jbossws-cxf-4.3 (was: jbossws-cxf-4.2) > JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor > ------------------------------------------------------------------------------------------ > > Key: JBWS-3378 > URL: https://issues.jboss.org/browse/JBWS-3378 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Richard Opalka > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3 > > > JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security > > Handlers associated with a Port component run after authorization has occurred and before the business logic > method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service endpoints, > Handlers run after the container has performed the security constraint checks associated with the servlet > element that defines the Port component. For EJB based service implementations, Handlers run after method > level authorization has occurred. > JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions > Handlers run under the transaction context of the component they are associated with. -- 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