August 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3671) AbstractServerConfig keep stale reference to server config after reboot

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3671?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3671: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 959426|https://bugzilla.redhat.com/show_bug.cgi?id=959426] from POST to MODIFIED > AbstractServerConfig keep stale reference to server config after reboot > ----------------------------------------------------------------------- > > Key: JBWS-3671 > URL: https://issues.jboss.org/browse/JBWS-3671 > 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 > > > As a consequence of JBWS-3576 fix, the AbstractServerConfig's reference to the AS container ServerConfig might turn into a stale object if the server is reloaded through management. We need to clean up the static references in such cases. -- 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

11 years, 3 months

1
0
0 / 0

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

by Joseph Hwang (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Joseph Hwang commented on JBWS-3648: ------------------------------------ Dear, Alessio! I solved my client-issue with your advice. But, this time I am struggling with server-side signature and encryption. @EndpointConfig annotation in my server class does not work. Pls, check this issue, https://community.jboss.org/thread/232031 > WS-Policy code-first improvements > --------------------------------- > > 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 > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3700) Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication

by Fernando Ribeiro (JIRA)

[ https://issues.jboss.org/browse/JBWS-3700?page=com.atlassian.jira.plugin.... ] Fernando Ribeiro updated JBWS-3700: ----------------------------------- Description: Any calls to the isUserInRole method of JAX-WS services with HTTP BASIC authentication are mis-returning false. (was: Any calls to the isUserInRole method a JAX-WS service with HTTP BASIC authentication mis-return false.) > Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication > -------------------------------------------------------------------- > > Key: JBWS-3700 > URL: https://issues.jboss.org/browse/JBWS-3700 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.1.3 > Environment: All supported environments. > Reporter: Fernando Ribeiro > Attachments: jaxwssample-1.0.war > > > Any calls to the isUserInRole method of JAX-WS services with HTTP BASIC authentication are mis-returning false. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3700) Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication

by Fernando Ribeiro (JIRA)

[ https://issues.jboss.org/browse/JBWS-3700?page=com.atlassian.jira.plugin.... ] Fernando Ribeiro updated JBWS-3700: ----------------------------------- Attachment: jaxwssample-1.0.war This test case requires a "SampleSecurityDomain" security domain, which you may want to configure to use the "UsersRoles" login module, for which configuration files are provided. > Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication > -------------------------------------------------------------------- > > Key: JBWS-3700 > URL: https://issues.jboss.org/browse/JBWS-3700 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.1.3 > Environment: All supported environments. > Reporter: Fernando Ribeiro > Attachments: jaxwssample-1.0.war > > > Any calls to the isUserInRole method a JAX-WS service with HTTP BASIC authentication mis-return false. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3700) Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication

by Fernando Ribeiro (JIRA)

Fernando Ribeiro created JBWS-3700: -------------------------------------- Summary: Unable to Check Roles in JAX-WS Service w/ HTTP BASIC Authentication Key: JBWS-3700 URL: https://issues.jboss.org/browse/JBWS-3700 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.1.3 Environment: All supported environments. Reporter: Fernando Ribeiro Any calls to the isUserInRole method a JAX-WS service with HTTP BASIC authentication mis-return false. -- 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

11 years, 3 months

1
0
0 / 0

[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: ----------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 913411|https://bugzilla.redhat.com/show_bug.cgi?id=913411] Marking for exclusion from the 6.1.1 Release Notes document as an entry for this bug could not be completed or verified in time. > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3699) Add WebServiceFeature for creating JAXWS Service in a new CXF Bus

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3699?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3699: ---------------------------------- Description: The issue at https://issues.jboss.org/browse/JBWS-3692 made it clear that there are scenarios in which even a plain JAXWS user might not want a client to be created in the current thread bus (which is the default behavior). In JBWS-3692 the reason was related to the WSDLManager cache in the bus, but we could possibly have other reasons. So, leveraging JAXWS 2.2 option for setting WebServiceFeature at JAXWS Service creation, we could provide a feature for requesting a new bus to created and used to build the Service, without requiring the user to manually deal with Apache CXF Bus / BusFactory instances. was: The issue at https://issues.jboss.org/browse/JBWS-3692 made it clear that there are scenarios in which the user might not want a client to be created in the current thread bus (which is the default behavior). In JBWS-3692 the reason was related to the WSDLManager cache in the bus, but we could possibly have other reasons. So, leveraging JAXWS 2.2 option for setting WebServiceFeature at JAXWS Service creation, we could provide a feature for requesting a new bus to created and used to build the Service, without requiring the user to manually deal with Apache CXF Bus / BusFactory instances. > Add WebServiceFeature for creating JAXWS Service in a new CXF Bus > ----------------------------------------------------------------- > > Key: JBWS-3699 > URL: https://issues.jboss.org/browse/JBWS-3699 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.1 > > > The issue at https://issues.jboss.org/browse/JBWS-3692 made it clear that there are scenarios in which even a plain JAXWS user might not want a client to be created in the current thread bus (which is the default behavior). In JBWS-3692 the reason was related to the WSDLManager cache in the bus, but we could possibly have other reasons. > So, leveraging JAXWS 2.2 option for setting WebServiceFeature at JAXWS Service creation, we could provide a feature for requesting a new bus to created and used to build the Service, without requiring the user to manually deal with Apache CXF Bus / BusFactory instances. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3699) Add WebServiceFeature for creating JAXWS Service in a new CXF Bus

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3699: ------------------------------------- Summary: Add WebServiceFeature for creating JAXWS Service in a new CXF Bus Key: JBWS-3699 URL: https://issues.jboss.org/browse/JBWS-3699 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.2.1 The issue at https://issues.jboss.org/browse/JBWS-3692 made it clear that there are scenarios in which the user might not want a client to be created in the current thread bus (which is the default behavior). In JBWS-3692 the reason was related to the WSDLManager cache in the bus, but we could possibly have other reasons. So, leveraging JAXWS 2.2 option for setting WebServiceFeature at JAXWS Service creation, we could provide a feature for requesting a new bus to created and used to build the Service, without requiring the user to manually deal with Apache CXF Bus / BusFactory instances. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3690) XMLJavaTypeAdapter not working in Exception Classes

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated JBWS-3690: --------------------------------- Attachment: cxf5219.diff > XMLJavaTypeAdapter not working in Exception Classes > --------------------------------------------------- > > Key: JBWS-3690 > URL: https://issues.jboss.org/browse/JBWS-3690 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2 > Reporter: Mustafa Musaji > Assignee: Mustafa Musaji > Attachments: cxf5219.diff, cxfTest.jar > > > @XMLJavaTypeAdapter usage in Exception Classes does not work when mapping to a class not in the JAXB Context. > {code:title=MyEJB.java} > @Stateless > @WebService > public class MyEJB { > public void launcheMyException() throws MyException { > return; > } > } > {code} > {code:title=MyException.java} > @XmlAccessorType(XmlAccessType.FIELD) > public class MyException extends Exception { > @XmlJavaTypeAdapter(Cl1ToCl2Adapter.class) > MyClass1 obj1; > @XmlJavaTypeAdapter(NoArgObjAdapter.class) > NoArgObj obj2; > public MyClass1 getObj1() { > return obj1; > } > > public void setObj1(MyClass1 obj1) { > this.obj1 = obj1; > } > public NoArgObj getObj2() { > return obj2; > } > public void setObj2(NoArgObj obj2) { > this.obj2 = obj2; > } > } > {code} > {code:title=Cl1ToCl2Adapter.java} > public class Cl1ToCl2Adapter extends XmlAdapter<MyClass2,MyClass1> { > @Override > public MyClass2 marshal(MyClass1 v) throws Exception { > return new MyClass2(); > } > @Override > public MyClass1 unmarshal(MyClass2 v) throws Exception { > MyClass1 mc1 = new MyClass1(v.getS2()); > return mc1; > } > } > {code} > This is what the resulting WSDL contains. Obj2 is mapped fine to a String, but MyClass1 is not and should have the MyClass2 mapping here. > {code:xml} > <xs:complexType name="MyException"> > <xs:sequence> > <xs:element name="str" nillable="true" type="xs:string"/> > <xs:element name="obj2" nillable="true" type="xs:string"/> > </xs:sequence> > </xs:complexType> > {code} > If you add the same adapter to a non Exception class it works just fine. > This is NOT a duplicate of JBWS-3552 as I believe in that use case only known JAXB types were tested (HashMap, Strings etc). This issue is when you are using custom classes that need to be mapped. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3698) Fix regressions in SOAP-over-JMS testcases on WildFly 8.0.0.Alpha3

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3698?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3698: ---------------------------------- Issue Type: Task (was: Feature Request) > Fix regressions in SOAP-over-JMS testcases on WildFly 8.0.0.Alpha3 > ------------------------------------------------------------------ > > Key: JBWS-3698 > URL: https://issues.jboss.org/browse/JBWS-3698 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration, productization > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.1 > > > Starting from WildFly 8.0.0.Alpha3 we have some regressions in SOAP-over-JMS testcases. We need to update the JNDI url to be used for resolving the remote connection factory, given WFLY now uses HTTP Upgrade. -- 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

11 years, 3 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 August 2013