November 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3729) Fix org.jboss.test.ws.jaxws.cxf.noIntegration.CXFEndpointServlet

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3729: ------------------------------------- Summary: Fix org.jboss.test.ws.jaxws.cxf.noIntegration.CXFEndpointServlet Key: JBWS-3729 URL: https://issues.jboss.org/browse/JBWS-3729 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, productization Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3 The org.jboss.test.ws.jaxws.cxf.noIntegration.CXFEndpointServlet that is used by the DisabledWSSubsystemTestCase is leaving the bus created within the CXFNonSpringServlet assigned to the thread that's serving the servlet init() method. That can lead to intermittent failures in other tests that use the Endpoint.publish(..) api for starting endpoints within other servlets. -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3728) Add a callback handler mechanism for controlling attribute updates in AbstractServerConfig

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3728: ------------------------------------- Summary: Add a callback handler mechanism for controlling attribute updates in AbstractServerConfig Key: JBWS-3728 URL: https://issues.jboss.org/browse/JBWS-3728 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3 We need to allow extenders of the AbstractServerConfig to provide callback handlers to control the set/update of basic attributes (webserviceHost, webservicePort, webserviceSecurePort, modifySOAPAddress). -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3727) NPE in org.jboss.wsf.stack.cxf.interceptor.HandlerAuthInterceptor

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3727: ------------------------------------- Summary: NPE in org.jboss.wsf.stack.cxf.interceptor.HandlerAuthInterceptor Key: JBWS-3727 URL: https://issues.jboss.org/browse/JBWS-3727 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.2.2 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3 java.lang.NullPointerException at org.jboss.wsf.stack.cxf.interceptor.HandlerAuthInterceptor$JBossWSHandlerChainInvoker.checkAuthorization(HandlerAuthInterceptor.java:150) at org.jboss.wsf.stack.cxf.interceptor.HandlerAuthInterceptor$JBossWSHandlerChainInvoker.invokeProtocolHandlers(HandlerAuthInterceptor.java:110) at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessageInternal(SOAPHandlerInterceptor.java:169) at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:124) at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:71) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) [...] -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3719) ServiceContainerEndpointRegistry#getRegisteredEndpoints() returns set containing null

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3719?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3719: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> changed the Status of [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] from ON_QA to VERIFIED > ServiceContainerEndpointRegistry#getRegisteredEndpoints() returns set containing null > ------------------------------------------------------------------------------------- > > Key: JBWS-3719 > URL: https://issues.jboss.org/browse/JBWS-3719 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration, jbossws-native > Affects Versions: jbossws-cxf-4.2 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.2 > > > The ServiceContainerEndpointRegistry#getRegisteredEndpoints() can return a set containing null as the retrieval of the service list from the container service registry plus the lookup of each service corresponding to the name is not atomic. We need to protect against this, as the consumers of org.jboss.wsf.spi.management.EndpointRegistry#resolve(EndpointResolver resolver) choke on it with NPEs. -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3719) ServiceContainerEndpointRegistry#getRegisteredEndpoints() returns set containing null

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3719?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3719: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> made a comment on [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] verified - I've check test failures with symptoms described are not present on EAP 6.2.0.ER7 > ServiceContainerEndpointRegistry#getRegisteredEndpoints() returns set containing null > ------------------------------------------------------------------------------------- > > Key: JBWS-3719 > URL: https://issues.jboss.org/browse/JBWS-3719 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration, jbossws-native > Affects Versions: jbossws-cxf-4.2 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.2 > > > The ServiceContainerEndpointRegistry#getRegisteredEndpoints() can return a set containing null as the retrieval of the service list from the container service registry plus the lookup of each service corresponding to the name is not atomic. We need to protect against this, as the consumers of org.jboss.wsf.spi.management.EndpointRegistry#resolve(EndpointResolver resolver) choke on it with NPEs. -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3717) EndpointResolver implementations do not verify endpoint state before using endpoint

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3717: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> changed the Status of [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] from ON_QA to VERIFIED > EndpointResolver implementations do not verify endpoint state before using endpoint > ----------------------------------------------------------------------------------- > > Key: JBWS-3717 > URL: https://issues.jboss.org/browse/JBWS-3717 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration, jbossws-native > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.2 > > > Currently the implementors of EndpointResolver (namely, WebAppResolver and PortComponentResolver do not check the state of an endpoint before trying using it. This is a problem as with JBWS-3643 the EndpointRegistry is now based on the AS service registry, so it's possible for the resolvers to see endpoints that are not started yet. The issue would likely affect scenarios with frequent and concurrent deploy/undeploy sequences or requests reaching the AS during boot. -- 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

1
0
0 / 0

[JBoss JIRA] (JBWS-3717) EndpointResolver implementations do not verify endpoint state before using endpoint

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3717: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> made a comment on [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] verified - I've check test failures with symptoms described are not present on EAP 6.2.0.ER7 > EndpointResolver implementations do not verify endpoint state before using endpoint > ----------------------------------------------------------------------------------- > > Key: JBWS-3717 > URL: https://issues.jboss.org/browse/JBWS-3717 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration, jbossws-native > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.2 > > > Currently the implementors of EndpointResolver (namely, WebAppResolver and PortComponentResolver do not check the state of an endpoint before trying using it. This is a problem as with JBWS-3643 the EndpointRegistry is now based on the AS service registry, so it's possible for the resolvers to see endpoints that are not started yet. The issue would likely affect scenarios with frequent and concurrent deploy/undeploy sequences or requests reaching the AS during boot. -- 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

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3690: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> changed the Status of [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893] from ON_QA to VERIFIED > 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 > Fix For: jbossws-cxf-4.2.2 > > 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

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3690: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> made a comment on [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893] Verify using attachment from comment#9 EAP 6.2.0.ER7 passed EAP 6.2.0.ER6 failed > 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 > Fix For: jbossws-cxf-4.2.2 > > 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

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3690: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> made a comment on [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893] mvn verify -Djboss.home=/home/development/jbossqe/JBEAP-6.2.0.ER6/build/jboss-eap-6.2 > 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 > Fix For: jbossws-cxf-4.2.2 > > 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

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 November 2013