I have a vanilla CXF web service deployed in JBoss 5.1.0. All the cxf jars, and dependencies are in the war file.
I am enabling class loading isolation, using jboss-classloading.xml in WEB-INF. The
problem I am running into is that, the application is not successfully
deployed (exception below). I tried adding
org.apache.tomcat/annotations-api as suggested in another thread, but
that does not seem to work.
The deployment error is always one of the following one:
-mapped-name is required for org.apache.cxf.transport.http.QueryHandlerRegistryImpl/bus
-mapped-name is required for org.apache.cxf.binding.AbstractBindingFactory/bus of deployment
-mapped-name is required for org.apache.cxf.catalog.OASISCatalogManager/bus
-mapped-name is required for cxf
Turning off class loading isolation, makes the problem go away, but
then I have to keep removing jars from the war. Any help is greatly
The detailed exception is as follows:
java.lang.RuntimeException: mapped-name is required for ...
org.apache.cxf.binding.AbstractBindingFactory/bus of deployment ws.war
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I'm on 5.1.0 also. I'm not using jboss-classloading.xml. My procedure was to examine the instructions in WHICH_JARS, which is included with CXF, and I skipped all of the geronimo files since JBoss provides these dependencies. You should only include a small fraction of the jars included with CXF. The only exception to the geronimo jar rule was that I received the above error "mapped-name is required for ..." The solution was to include geronimo-annotation.jar in the lib directory of my web application.
This may not be of help to you, but maybe someone will benefit?
Only yesterday I just stumbled across the same problem.
We're using JBoss EAP 5.1.0b here as well and I wanted to bundle Apache CXF within my WAR file and had a cxf.xml that works perfectly well when using Jetty.
I then found this blog post:
(Suggestion was to add the geronimo-annotation-spec-1.1.1.jar into WEB-INF/lib/ of the .war-file)
The above mentioned suggested additional JAR file solves the classloading issue for some reason. -- playing around with jboss-classloading.xml did not do the trick for me.
I don't know much about the JBoss classloading mechanism and I don't like the solution "just add an additional jar file - it will work!" very much.
But maybe this will shed some more light on the whole situation and help figure out the true cause of the original issue.