August 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3796) CXFHandlerResolverImpl initializes handlers at each getHandlerChain() invocation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3796?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3796: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > CXFHandlerResolverImpl initializes handlers at each getHandlerChain() invocation > -------------------------------------------------------------------------------- > > Key: JBWS-3796 > URL: https://issues.jboss.org/browse/JBWS-3796 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > > org.jboss.wsf.stack.cxf.client.serviceref.CXFHandlerResolverImpl#getHandlerChain(PortInfo portInfo) uses a map to avoid building the handler chain multiple time for a given port info. However it performs initialization / injection on the handlers at each invocation. Moreover, the access to the map is not thread-safe. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3786) @Resource injection not working on handlers attached to JAX-WS clients running in-container

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3786?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3786: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > @Resource injection not working on handlers attached to JAX-WS clients running in-container > ------------------------------------------------------------------------------------------- > > Key: JBWS-3786 > URL: https://issues.jboss.org/browse/JBWS-3786 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3778) WS-Discovery and IPv6

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3778?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3778: ---------------------------------- Fix Version/s: (was: jbossws-cxf-5.0) > WS-Discovery and IPv6 > --------------------- > > Key: JBWS-3778 > URL: https://issues.jboss.org/browse/JBWS-3778 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: R Searls > > Apache CXF WSDiscoveryServiceImpl does > {code} > udpEndpoint.publish("soap.udp://239.255.255.250:3702"); > {code} > which is fine as long as an IPv4 network is available. > This can lead to the following exception when on a pure IPv6 network: > {noformat} > [0m[33m06:25:53,342 WARNING [org.apache.cxf.ws.discovery.WSDiscoveryService] (MSC service thread 1-2) Could not start WS-Discovery Service.: javax.xml.ws.WebServiceException: java.lang.RuntimeException: java.net.SocketException: No such device > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.jboss.wsf.stack.cxf.client.ProviderImpl$DelegateEndpointImpl.publish(ProviderImpl.java:421) [jbossws-cxf-client-4.3.0.Final.jar:4.3.0.Final] > at org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:247) [cxf-services-ws-discovery-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153) [cxf-services-ws-discovery-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73) [cxf-services-ws-discovery-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61) [cxf-rt-core-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:146) [cxf-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) [jbossws-cxf-server-4.3.0.Final.jar:4.3.0.Final] > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:118) [jbossws-cxf-server-4.3.0.Final.jar:4.3.0.Final] > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:137) [jbossws-cxf-server-4.3.0.Final.jar:4.3.0.Final] > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:69) [jbossws-cxf-server-4.3.0.Final.jar:4.3.0.Final] > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:74) [jboss-as-webservices-server-integration-7.4.0.Final-redhat-6.jar:7.4.0.Final-redhat-6] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > Caused by: java.lang.RuntimeException: java.net.SocketException: No such device > at org.jboss.wsf.stack.cxf.addons.transports.udp.UDPDestination.activate(UDPDestination.java:201) [jbossws-cxf-transports-udp-4.3.0.Final.jar:4.3.0.Final] > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) [cxf-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) [cxf-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:893) [cxf-rt-bindings-soap-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) [cxf-api-2.7.10.redhat-1.jar:2.7.10.redhat-1] > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) [cxf-rt-frontend-jaxws-2.7.10.redhat-1.jar:2.7.10.redhat-1] > ... 21 more > Caused by: java.net.SocketException: No such device > at java.net.PlainDatagramSocketImpl.join(Native Method) [rt.jar:1.8.0] > at java.net.AbstractPlainDatagramSocketImpl.join(AbstractPlainDatagramSocketImpl.java:178) [rt.jar:1.8.0] > at java.net.MulticastSocket.joinGroup(MulticastSocket.java:323) [rt.jar:1.8.0] > at org.jboss.wsf.stack.cxf.addons.transports.udp.UDPDestination.activate(UDPDestination.java:185) [jbossws-cxf-transports-udp-4.3.0.Final.jar:4.3.0.Final] > ... 26 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3777) CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3777?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3777: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.1 > CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL > ---------------------------------------------------------------- > > Key: JBWS-3777 > URL: https://issues.jboss.org/browse/JBWS-3777 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.2.3 > Environment: Red Hat JBoss EAP 6.2.0 > Reporter: Tadayoshi Sato > Assignee: Jim Ma > Fix For: jbossws-cxf-4.3.1, jbossws-cxf-5.0 > > Attachments: ws-rm.zip > > > Please port the fix for [CXF-5645|https://issues.apache.org/jira/browse/CXF-5645] to JBoss WS CXF. > Here is the original issue description: > The {{wsp:Optional}} attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support {{wsp:Optional}}, that is, if {{wsp:Optional}} is set to {{true}} on a WS-RM policy the WS-RM policy should become optional -- the endpoint should allow both messages with and without WS-RM \[1\]. However, my experimentation showed that it actually doesn't. > What I did is as follows (see the attached reproducer for details): > # Configured in WSDL ({{greeting.wsdl}}) an endpoint as optionally WS-RM enabled like the following: > {code:xml} > <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService"> > <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> > <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" > wsp:Optional="true" /> > <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy" > wsp:Optional="true" /> > </wsp:Policy> > ... > {code} > # Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault: > {code:xml} > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Body> > <soap:Fault> > <faultcode>soap:Server</faultcode> > <faultstring>WS-Addressing is required by this endpoint.</faultstring> > </soap:Fault> > </soap:Body> > </soap:Envelope> > {code} > [1] In WS-RM Policy 1.1 p.8: > {quote} > /wsrmp:RMAssertion/@wsp:Optional="true" > Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used. > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3786) @Resource injection not working on handlers attached to JAX-WS clients running in-container

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3786?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3786: ---------------------------------- Fix Version/s: (was: jbossws-cxf-4.3.1) > @Resource injection not working on handlers attached to JAX-WS clients running in-container > ------------------------------------------------------------------------------------------- > > Key: JBWS-3786 > URL: https://issues.jboss.org/browse/JBWS-3786 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3822) Default to TCCL bus strategy for clients running in-container

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3822?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3822: ---------------------------------- Description: For performance reasons, it makes sense to default to TCCL bus creation strategy on server side (that is, when running in-container). This means JAX-WS clients created on WildFly container will not use the bus linked to the current thread, but the one linked to the current thread context classloader. This effectively reduces the number of client busses by basically limiting it to the number of application deployments as well as prevents possible issues caused by thread pools (bus re-used by different applications...) See https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... for details on Bus creation strategies was:For performance reasons, it makes sense to default to TCCL bus creation strategy on server side (that is, when running in-container). This means JAX-WS clients created on WildFly container will not use the bus linked to the current thread, but the one linked to the current thread context classloader. This effectively reduces the number of client busses by basically limiting it to the number of application deployments as well as prevents possible issues caused by thread pools (bus re-used by different applications...) > Default to TCCL bus strategy for clients running in-container > ------------------------------------------------------------- > > Key: JBWS-3822 > URL: https://issues.jboss.org/browse/JBWS-3822 > 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-5.0 > > > For performance reasons, it makes sense to default to TCCL bus creation strategy on server side (that is, when running in-container). This means JAX-WS clients created on WildFly container will not use the bus linked to the current thread, but the one linked to the current thread context classloader. This effectively reduces the number of client busses by basically limiting it to the number of application deployments as well as prevents possible issues caused by thread pools (bus re-used by different applications...) > See https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... for details on Bus creation strategies -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3822) Default to TCCL bus selection strategy for clients running in-container

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3822?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3822: ---------------------------------- Summary: Default to TCCL bus selection strategy for clients running in-container (was: Default to TCCL bus strategy for clients running in-container) > Default to TCCL bus selection strategy for clients running in-container > ----------------------------------------------------------------------- > > Key: JBWS-3822 > URL: https://issues.jboss.org/browse/JBWS-3822 > 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-5.0 > > > For performance reasons, it makes sense to default to TCCL bus creation strategy on server side (that is, when running in-container). This means JAX-WS clients created on WildFly container will not use the bus linked to the current thread, but the one linked to the current thread context classloader. This effectively reduces the number of client busses by basically limiting it to the number of application deployments as well as prevents possible issues caused by thread pools (bus re-used by different applications...) > See https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... for details on Bus creation strategies -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3822) Default to TCCL bus strategy for clients running in-container

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3822: ------------------------------------- Summary: Default to TCCL bus strategy for clients running in-container Key: JBWS-3822 URL: https://issues.jboss.org/browse/JBWS-3822 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-5.0 For performance reasons, it makes sense to default to TCCL bus creation strategy on server side (that is, when running in-container). This means JAX-WS clients created on WildFly container will not use the bus linked to the current thread, but the one linked to the current thread context classloader. This effectively reduces the number of client busses by basically limiting it to the number of application deployments as well as prevents possible issues caused by thread pools (bus re-used by different applications...) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3821) WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3821?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3821: --------------------------------------- See also https://source.jboss.org/changelog/JBossWS?cs=18863 > WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies > ---------------------------------------------------------------------------------------------- > > Key: JBWS-3821 > URL: https://issues.jboss.org/browse/JBWS-3821 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > The WebServiceRef injection assumes the server is running with the THREAD bus strategy globally configured. If that's not the case, the server can end up using unexpected bus instances for webserviceref injected clients. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3821) WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3821?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3821: ---------------------------------- Summary: WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies (was: WebServiceRef injection not working with TCCL and NEW client Bus selection strategies) > WebServiceRef injection not working properly with TCCL and NEW client Bus selection strategies > ---------------------------------------------------------------------------------------------- > > Key: JBWS-3821 > URL: https://issues.jboss.org/browse/JBWS-3821 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > The WebServiceRef injection assumes the server is running with the THREAD bus strategy globally configured. If that's not the case, the server can end up using unexpected bus instances for webserviceref injected clients. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 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 2014