October 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3723) Remove io.netty:netty exclusion from jbossws-native dependency in jbossws-cxf main pom

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3723: ------------------------------------- Summary: Remove io.netty:netty exclusion from jbossws-native dependency in jbossws-cxf main pom Key: JBWS-3723 URL: https://issues.jboss.org/browse/JBWS-3723 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3 We've been erroneously and accidentally relying on various transitive dependencies for pulling in the io.netty:netty dependency needed by native stack to run jaxrpc tests. The issue comes from the netty dependency being excluded in the jbossws-native dependency in jbossws-cxf main pom and has been revealed when upgrading the littleshot littleproxy test dependency, which now uses netty 4 instead of 3. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3713) Allow better control over Apache CXF bus creation for JAXWS clients

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3713?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3713: --------------------------------------- Doc: https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... > Allow better control over Apache CXF bus creation for JAXWS clients > ------------------------------------------------------------------- > > Key: JBWS-3713 > URL: https://issues.jboss.org/browse/JBWS-3713 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.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, 6 months

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: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893] from ASSIGNED to MODIFIED > 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

10 years, 6 months

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: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] from POST to MODIFIED > 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

10 years, 6 months

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: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] from POST to MODIFIED > 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

10 years, 6 months

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: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893] from NEW to ASSIGNED > 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

10 years, 6 months

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 updated JBWS-3719: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017550 > 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

10 years, 6 months

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: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> changed the Status of [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] from NEW to POST > 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

10 years, 6 months

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: ----------------------------------------------- Alessio Soldano <asoldano(a)redhat.com> made a comment on [bug 1017550|https://bugzilla.redhat.com/show_bug.cgi?id=1017550] https://github.com/jbossas/jboss-eap/pull/576 > 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3706) JBossWS 4.2.1.Final errata

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3706?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3706: --------------------------------------- Same for JBossWS 4.2.2.Final > JBossWS 4.2.1.Final errata > --------------------------- > > Key: JBWS-3706 > URL: https://issues.jboss.org/browse/JBWS-3706 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2.1 > > -- 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, 6 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 October 2013