[mule-dev] javaxws client junit test with mule & cxf jars on the classpath

6 views
Skip to first unread message

Padraig ODowd

unread,
Jun 17, 2010, 11:54:52 AM6/17/10
to d...@mule.codehaus.org
Hi, I have deployed a cxf webservice on mule and I want to write a junit test to test the service. (I want to use a javaxws generate client in my test not a mule client)
The junit test just imports javax.xml.ws.WebServiceRef which is included in the normal jvm6 classpath. So the only other jar I added to my classpath is the junit jar. I generated the client stubs using the wsimport tool and added the generated code to my project's source. When I run this junit test/code in a standalone project in eclipse it works fine and produces the correct results.

When I try to move this junit test/code into the main product project I keep getting the exceptions below. The difference between the two projects, is that obviously there are a load of extra jars added to the classpath of the main project - mule, cxf, spring jars etc. So even though the code in the junit test does not require any of these jars there seems to be some jar loading conflict happening (which I cant seem to track down)? (Again when I run this code in a project with just the jvm6 and junit jars it works fine)

Thanks in advance for any help.

---------------------------------------------
The imports in my junit test:
---------------------------------------------
import javax.xml.ws.WebServiceRef;
import org.junit.Assert;
import org.junit.Test;

--------------------
Exceptions:
--------------------
javax.xml.ws.soap.SOAPFaultException: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
..
...
Caused by: org.apache.cxf.interceptor.Fault: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http.
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:89)
at org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:61)
at org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:472)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:293)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
... 25 more
Caused by: org.apache.cxf.BusException: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http.
at org.apache.cxf.transport.ConduitInitiatorManagerImpl.getConduitInitiator(ConduitInitiatorManagerImpl.java:111)
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:70)
... 31 more

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Padraig ODowd

unread,
Jun 18, 2010, 5:02:12 AM6/18/10
to d...@mule.codehaus.org
I tracked down the jar to cxf-rt-ws-addr-2.1.2.jar. Though the problem might be caused by another jar higher up the dependency graph as before I added cxf-rt-ws-addr-2.1.2.jar I was getting class not found exceptions at runtime - so all I know for sure at the moment is that the problem is caused by either cxf-rt-ws-addr-2.1.2.jar or some jar that depends on it.

Padraig ODowd

unread,
Jun 18, 2010, 6:39:49 AM6/18/10
to d...@mule.codehaus.org
Attached image shows all files added to the classpath - one of these is causing the problem

Edu Pereda

unread,
Jun 18, 2010, 7:24:31 AM6/18/10
to dev
Hi, Padraig,

The attached image didn't make it. I don't know if attachments are disabled or if you forgot to attach it.
If you are using eclipse you can paste the contents of .classpath file, perhaps.

Anyway, can you share the code of your unit test?

Edu

Padraig ODowd

unread,
Jun 18, 2010, 11:38:25 AM6/18/10
to d...@mule.codehaus.org
Hi Edu,

Thanks for your reply.

Here is a list of the jars that are added to the classpath, one of these is causing the problem:
junit-4.4.jar
cxf-rt-transports-local-2.1.2.jar
cxf-api-2.1.2.jar
cxf-tools-common-2.1.2.jar
cxf-rt-frontend-jaxws-2.1.2.jar
cxf-common-utilities-2.1.2.jar
cxf-rt-core-2.1.2.jar
wsdl4j-1.6.2.jar
xml-resolver-1.2.jar
cxf-rt-frontend-simple-2.1.2.jar
cxf-rt-bindings-soap-2.1.2.jar
cxf-rt-databinding-jaxb-2.1.2.jar
webservices-rt-1.1.jar
cxf-rt-ws-addr-2.1.2.jar
XmlSchema-1.4.2.jar

The junit one is the only one required by my test below, when I remove the others the code works fine.

-----------------
Junit test:
-----------------
import javax.xml.ws.WebServiceRef;

import org.junit.Assert;
import org.junit.Test;

public class PolicyValidationDetailsServiceImplMuleTest {
@WebServiceRef(wsdlLocation="http://localhost:9090/services/policyValidationDetailsService?wsdl")
static PolicyValidationDetailsServiceImplService policyValidationService;

public void runTest_PolicyNumberExists() {
//Stubs were generated using wsimport tool and the generated client code was imported into to
//the project
policyValidationService = new PolicyValidationDetailsServiceImplService();
Assert.assertNotNull(policyValidationService);

PolicyValidationDetailsServiceMessage message = new PolicyValidationDetailsServiceMessage();
message.setPolicyReference("123456789");

PolicyValidationDetailsServiceMessage returnMessage = policyValidationService.getPolicyValidationDetailsServiceImplPort().getValidationDetails(message);

Assert.assertNotNull(returnMessage);
Assert.assertEquals(new Integer(0), returnMessage.getStatus().getCode());
Assert.assertEquals("AgentCode1", returnMessage.getAgentCode());
}

@Test
public void testWebservice() {
PolicyValidationDetailsServiceImplMuleTest test = new PolicyValidationDetailsServiceImplMuleTest();
test.runTest_PolicyNumberExists();
}


The line below is what is throwing the exception in my test only when the jars above are added to the classpath (That object was generated using the wsimport tool)

PolicyValidationDetailsServiceMessage returnMessage = policyValidationService.getPolicyValidationDetailsServiceImplPort().getValidationDetails(message);

Andrew Perepelytsya

unread,
Jun 18, 2010, 11:48:58 AM6/18/10
to d...@mule.codehaus.org
Mule has upgraded cxf libraries in more recent releases. Have you tried dropped a newer cxf? E.g. their site features 2.1.10 as of today.

Andrew

Padraig ODowd

unread,
Jun 18, 2010, 12:05:28 PM6/18/10
to d...@mule.codehaus.org
Thanks Andrew,
I haven't tried that yet but will do now. Quick question might there be any problems using these newer jars with mule 2.2.1. Our project is tied to that version of mule.

Andrew Perepelytsya

unread,
Jun 18, 2010, 12:08:43 PM6/18/10
to d...@mule.codehaus.org


On Fri, Jun 18, 2010 at 12:05 PM, Padraig ODowd <mule.de...@mulesource.com> wrote:
Thanks Andrew,
I haven't tried that yet but will do now. Quick question might there be any problems using these newer jars with mule 2.2.1. Our project is tied to that version of mule.


I really don't know. When we upgrade dependencies, they go with a specific Mule version. The 2.2.1 is more than a year old, I can't say if it had changes to address cxf upgrade (it might have). Only trial and error can tell.

Andrew

Padraig ODowd

unread,
Jun 21, 2010, 6:58:17 AM6/21/10
to d...@mule.codehaus.org
Thanks Andrew, the project I'm working on is fixed to version 2.2.1 of Mule, so I'm not allowed to go upgrading the version of Mule used.
Reply all
Reply to author
Forward
0 new messages