April 2011 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-3229) DOMUtils issue on test classpath

by Richard Opalka (JIRA)

DOMUtils issue on test classpath -------------------------------- Key: JBWS-3229 URL: https://issues.jboss.org/browse/JBWS-3229 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Richard Opalka Fix For: jbossws-native-4.0, jbossws-cxf-4.0 junit.framework.AssertionFailedError: NonAnonymousResponses <------>at junit.framework.Assert.fail(Assert.java:47) <------>at junit.framework.Assert.assertTrue(Assert.java:20) <------>at junit.framework.Assert.assertNotNull(Assert.java:220) <------>at org.jboss.test.ws.jaxws.jbws2960.JBWS2960TestCase.testPolicyReference(JBWS2960TestCase.java:107) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-3270) AS7 org.jboss.as.webservices:main module should not have any stack specific dependencies

by Alessio Soldano (JIRA)

AS7 org.jboss.as.webservices:main module should not have any stack specific dependencies ---------------------------------------------------------------------------------------- Key: JBWS-3270 URL: https://issues.jboss.org/browse/JBWS-3270 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3274) Restore jaxbintros functionalities on AS7

by Alessio Soldano (JIRA)

Restore jaxbintros functionalities on AS7 ----------------------------------------- Key: JBWS-3274 URL: https://issues.jboss.org/browse/JBWS-3274 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-native Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3216) Investigate & fix test failures against AS7

by Richard Opalka (JIRA)

Investigate & fix test failures against AS7 ------------------------------------------- Key: JBWS-3216 URL: https://issues.jboss.org/browse/JBWS-3216 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Richard Opalka Fix For: jbossws-native-4.0, jbossws-cxf-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBWS-3268) REPLACE_WITH_ACTUAL_URL does not work for more than one Port in a WSDL

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3268?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3268: ---------------------------------- Assignee: (was: Alessio Soldano) Environment: (was: JBoss Enterprise Application Platform 5.1) > REPLACE_WITH_ACTUAL_URL does not work for more than one Port in a WSDL > ---------------------------------------------------------------------- > > Key: JBWS-3268 > URL: https://issues.jboss.org/browse/JBWS-3268 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ws-addressing > Reporter: Mustafa Musaji > > If you have a WSDL that contains more than one port and want the wsdl address location to be changed as per the jboss-beans.xml file this does not work. Only the first port will have it's location changed. The second will remain as REPLACE_WITH_ACTUAL_URL value and no error displayed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3267) JAXB Accessor Optimisation lost for SOA-P supplied endpoints when using signed jars

by Rick Wagner (JIRA)

JAXB Accessor Optimisation lost for SOA-P supplied endpoints when using signed jars ----------------------------------------------------------------------------------- Key: JBWS-3267 URL: https://issues.jboss.org/browse/JBWS-3267 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Environment: As used in SOA-P. Please fix what will go into EAP 5.1.1, as that will go into SOA-P 5.2. Reporter: Rick Wagner As described in SOA-2158, "When a JAXB context is first initialised for the classes that will be marshalled to eliminate any reflection overhead strongly typed accessor classes are generated to access the fields of the classes and the classes are then defined using the current classloader." Please see SOA-2158 for more details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3266) Update stax-api dependency

by Alessio Soldano (JIRA)

Update stax-api dependency -------------------------- Key: JBWS-3266 URL: https://issues.jboss.org/browse/JBWS-3266 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-native Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 We currently use (and install in lib/endorsed on AS6) stax:stax-api:1.0.1 while we should use the one that's also consumed by jaxb 2.2, which is javax.xml.stream:stax-api:1.0-2 . That also doesn't have an old javax.xml.XMLConstants class that would overwrite the one coming from JDK on AS6 due to endorsing, finally causing issues when trying acessing XMLConstants.FEATURE_SECURE_PROCESSING public attribute. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3265) Isolate deployment classloader from ws server integration

by Alessio Soldano (JIRA)

Isolate deployment classloader from ws server integration --------------------------------------------------------- Key: JBWS-3265 URL: https://issues.jboss.org/browse/JBWS-3265 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-native Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 We need to avoid exposing ws stacks implementation classes (and all their dependencies) to the user classpath. This implies completely reviewing the classloading in both JBossWS-Native and JBossWS-CXF to make sure the proper classloader is used depending on the needs instead of generally going through the thread context classloader. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3263) CLONE - org.w3c.dom.DOMException when create dispatch with EPR

by Kyle Lape (JIRA)

CLONE - org.w3c.dom.DOMException when create dispatch with EPR --------------------------------------------------------------- Key: JBWS-3263 URL: https://issues.jboss.org/browse/JBWS-3263 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native, ws-addressing Affects Versions: jbossws-native-3.4.1 Reporter: Kyle Lape Assignee: Jim Ma Fix For: jbossws-native-4.0 0:40:43,972 INFO [STDOUT] WS ADDR=<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/Quickstart_bpel_simple_invoke/HelloWorldWS</Address><Metadata><wsam:ServiceName EndpointName="HelloWorldPort" xmlns="http://simple_invoke/helloworld" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">HelloWorldWSService</wsam:ServiceName></Metadata></EndpointReference> 10:40:44,153 ERROR [HandlerChainExecutor] Exception during handler processing org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it. at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown Source) at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source) at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source) at org.jboss.ws.core.soap.NodeImpl.appendChild(NodeImpl.java:481) at org.jboss.ws.core.soap.SOAPHeaderImpl.appendChild(SOAPHeaderImpl.java:198) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:264) at org.jboss.ws.core.soap.SOAPHeaderImpl.addChildElement(SOAPHeaderImpl.java:70) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:233) at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:267) at org.jboss.ws.extensions.addressing.jaxws.WSAddressingClientHandler.handleOutbound(WSAddressingClientHandler.java:139) at org.jboss.wsf.common.handler.GenericHandler.handleMessage(GenericHandler.java:53) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:328) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:146) at org.jboss.ws.core.jaxws.client.DispatchImpl.callRequestHandlerChain(DispatchImpl.java:640) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:256) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:180) at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:147) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable$1.call(WebServiceClient.java:355) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:289) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:246) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable.call(WebServiceClient.java:231) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Only thing I am doing is: org.apache.ode.bpel.iapi.EndpointReference odeepr=mex.getEndpointReference(); javax.xml.ws.EndpointReference epr=null; if (odeepr != null) { if (odeepr instanceof org.apache.ode.bpel.epr.URLEndpoint) { org.apache.ode.bpel.epr.URLEndpoint url=(org.apache.ode.bpel.epr.URLEndpoint)odeepr; javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder builder= new javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder(); epr = builder.address(url.getUrl()) .serviceName(serviceName) .endpointName(port) .build(); System.out.println("WS ADDR="+epr); Creating the EPR from the ODE endpoint reference, and then if (epr != null) { dispatcher = service.createDispatch( epr, SOAPMessage.class, Service.Mode.MESSAGE, new javax.xml.ws.soap.AddressingFeature() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWS-3260) modifySOAPAddress = true ends up rewriting WSDLS for WebServiceClient code as well

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3260?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3260: ---------------------------------- Fix Version/s: jbossws-cxf-4.0 (was: jbossws-native-4.0) > modifySOAPAddress = true ends up rewriting WSDLS for WebServiceClient code as well > ---------------------------------------------------------------------------------- > > Key: JBWS-3260 > URL: https://issues.jboss.org/browse/JBWS-3260 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Environment: Linux x64, Java 6 > Reporter: borfnorton22 borfnorton22 > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.0 > > > We recent upgraded from Jboss 4.22 to Jboss 6. > The code I am describing below works fine on 4.2.2. > a) We have a JAX-WS generated client > b) The generated client code is configured to talk to a remote webservice and it calls a method on it as follows. > URL url = new URL("http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?O..."); > NetterService netterService = new NetterService(url); > netterService.getNetterServicePort().isNetAvailable("someNetName"); > The remote web-services WSDL exposes its service endpoint address as follows: > <service name="NetterService"> > <port binding="impl:NetterServicePortSoapBinding" name="NetterServicePort"> > <wsdlsoap:address location="http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?O..."/> > </port> > </service> > c) When this is running on Jboss 4.2.2 it works fine and has for quite some time. When the code executes on our JB6 server we see this is the logs which is absolutely bizzarre! Something in JB6 (cxf AddressRewritingEndpointInfo) is re-writing the hostname portion of the endpoint out client needs to talk to to a different host. This totally fails as when it trys to make a call we get a 404. > 11:02:38,377 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating Service {urn:DefaultNamespace}NetterService from WSDL: http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?O... > 11:02:38,378 INFO [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] Setting new service endpoint address in wsdl: http://ws-stage.fishing89k41.com/Netter/NetterSyncQ.nsf/NetterWS > 11:02:38,394 INFO [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] Setting new service endpoint address in wsdl: http://ws-stage.fishing89k41.com/Netter/NetterSyncQ.nsf/NetterWS > 11:02:38,406 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for {urn:DefaultNamespace}NetterService#{urn:DefaultNamespace}isNetAvailable has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not send Message. > at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64) [:2.3.1] > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [:2.3.1] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516) [:2.3.1] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313) [:2.3.1] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265) [:2.3.1] > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) [:2.3.1] > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) [:2.3.1] > at $Proxy302.isNetAvailable(Unknown Source) at some.service.SomeService. > We edited this file: deployers/jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml > and turned this OFF (rewrite to false) > <property name="modifySOAPAddress">false</property> > Once we did this the above rewrite went away, however isn't this a bug?? The documentation @ http://community.jboss.org/wiki/JBossWS-UserGuide under (Address Rewrite). It states this configuration is for deployed services. This is not a deployed service but a ws client. We are seeing this do rewrites for endpoints defined in remotely retrieved WSDLS for WebServiceClient code.....as shown above. > @ see http://community.jboss.org/thread/164507 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 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 April 2011