Having the exact same problem using Apache CXF 2.5.0 and WS-Security enabled.  With WS-Security disabled the service works fine.  With it on I get the trace below:

SOAP FAULT STACKTRACE:javax.xml.soap.SOAPException: Unable to create message factory for SOAP: java.lang.reflect.InvocationTargetException

1. javax.xml.soap.SOAPException: Unable to create message factory for SOAP: java.lang.reflect.InvocationTargetException

at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:112) ~[jboss-saaj-api_1.3_spec-1.0.1.Final.jar!/:1.0.1.Final]

at org.apache.cxf.binding.soap.saaj.SAAJFactoryResolver.createMessageFactory(SAAJFactoryResolver.java:56) ~[cxf-rt-bindings-soap-2.5.0.jar:na]

at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.getFactory(SAAJInInterceptor.java:148) ~[cxf-rt-bindings-soap-2.5.0.jar:na]

at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.handleMessage(SAAJInInterceptor.java:131) ~[cxf-rt-bindings-soap-2.5.0.jar:na]

at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.handleMessage(SAAJInInterceptor.java:105) ~[cxf-rt-bindings-soap-2.5.0.jar:na]

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) ~[cxf-api-2.5.0.jar:na]

at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123) [cxf-rt-core-2.5.0.jar:na]

at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:193) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:126) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107) [cxf-rt-transports-http-2.5.0.jar:na]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar!/:1.0.0.Final]

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163) [cxf-rt-transports-http-2.5.0.jar:na]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.0.2.Final.jar!/:7.0.2.Final]

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:480) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.2.Final.jar!/:7.0.2.Final]

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar!/:7.0.2.Final]

at java.lang.Thread.run(Thread.java:722) [na:1.7.0]

As a general comment, I suggest you to use the JBossWS-CXF / Apache CXF libraries that are available on AS7, instead of bundling Apache CXF 2.5.0 or Spring-WS.

This said, in order for figuring out what's happening here, you should probably try looking for the actual cause (I guess a CNFE) of the exception you posted above. I would do that by enabling TRACE level logging for the org.jboss.modules package and carefully looking at the logs just before the exceptions above first occur.

Alessio,

Thanks for responding.  To answer your question:

1. I have turned on TRACE level logging but Jboss is eating the exception.  They are just throwing...

throw new SoapException("Unable to create message factory for SOAP:" + ex.getMessage);

...and no stack trace, so I can see the root error.

2. I thought someone might suggest installing CXF and Spring as a Jboss7 module.  However that defeats the purpose of a portable WAR file.  If I have Jetty 8, Tomcat 7 and Jboss 7AS in my organization now I need to build custom WAR files and deployments for each platform.  I would prefer not to have to know that Jboss 7 AS is the destination platform when I build my WAR file.  Plus it will require the Unix Admins here (I am not allowed to touch Production Servers) to have to tweak Jboss 7AS to put CXF and Spring as modules in the environment etc.  I want to keep configuration of the actual container to a minimum.

Thanks,

    Mello

Hi,

Melloware Inc wrote:

 

Alessio,

 

Thanks for responding.  To answer your question:

 

1. I have turned on TRACE level logging but Jboss is eating the exception.  They are just throwing...

 

throw new SoapException("Unable to create message factory for SOAP:" + ex.getMessage);

 

...and no stack trace, so I can see the root error.

Did you also add a logger category for org.jboss.modules package?

2. I thought someone might suggest installing CXF and Spring as a Jboss7 module.  However that defeats the purpose of a portable WAR file.  If I have Jetty 8, Tomcat 7 and Jboss 7AS in my organization now I need to build custom WAR files and deployments for each platform.  I would prefer not to have to know that Jboss 7 AS is the destination platform when I build my WAR file.  Plus it will require the Unix Admins here (I am not allowed to touch Production Servers) to have to tweak Jboss 7AS to put CXF and Spring as modules in the environment etc.  I want to keep configuration of the actual container to a minimum.

Well, generally speaking when deploying on JBoss AS you should consider you're deploying against a Java EE container that comes with webservices functionalities, hence you're not supposed to provide your own ws impl.

If you want to use JBoss AS 7 as a "simple" web container, an idea might be to disable the webservices subsystem in the standalone configuration you're using. I didn't try that, but I guess that might work for you in this case.

There're multiple reasons for having the CXF libs included in the AS, most of them basically comes from JavaEE certification requirements. To be honest, there's even https://issues.jboss.org/browse/AS7-537 (part of https://issues.jboss.org/browse/AS7-388) which is about filtering out Apache CXF libs in user deployments to avoid clashes.

Generally speaking, a portable application should be built using standards only. So write a standard jaxws application with no direct reference to Apache CXF, Spring, etc. and you won't have portability problems (you'd just have to apply minor changes to web.xml descriptor for stuff not covered by spec there, but nowadays you can even get rid of web.xml...).

If you're directly leveraging specific implementation / libs / tools, unfortunately you need to deal with this kind of issues.

Alessio,

Thank you so much.  You are right I added the following jboss-deployment-structure.xml to my /WEB-INF/ folder and essentially I have turned Jboss into a stripped down web application server by excluding all the EE features and allowing my WAR to contain Apache CXF 2.5.0 etc.

<jboss-deployment-structure>

    <!-- For JBoss7AS and WS-Security to play nice must exclude the SAAJ jars -->

    <!-- This is the top level ear module, which contains all the classes in the EAR's lib folder     -->

    <deployment>

        <exclusions>

            <module name="javaee.api" />

        </exclusions>

    </deployment>

</jboss-deployment-structure>