Thanks, Daniel. That got me past that roadblock. Now on to the next one:
I make it through the service constructor - but I still can't use the
service.
Jan 22, 2010 7:19:49 AM org.apache.cxf.BusFactory newInstance
SEVERE: Failed to instantiate bus factory.
java.lang.ClassNotFoundException: org.apache.cxf.bus.CXFBusFactory
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at
org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:236)
at
org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:222)
at org.apache.cxf.BusFactory.newInstance(BusFactory.java:164)
at org.apache.cxf.BusFactory.newInstance(BusFactory.java:140)
at org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:69)
at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:106)
at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:97)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:64)
I've searched on javacious and it doesn't tell me that name of any jar
that supplies this class.
Waaaaaah!
Steve
Daniel Kulp wrote:
>> jaxb-api-2.0.jar
>> jaxb-impl-2.0.5.jar
>
> Those are probably the issue. CXF 2.2.x and 2.1.x require JAXB 2.1. Thus,
> it should be jaxb-api-2.1.jar and jaxb-impl-2.1.12.jar.
>
> Dan
>
>
>
>
> On Thu January 21 2010 11:05:59 pm Steve Cohen wrote:
>> I suspect that this may be dependency related. First of all, it doesn't
>> work in this maven setup if I dial back to CXF 2.0.7. Same problem
>> there, although 2.0.7 worked before I switched to Maven. There are other
>> Web Service clients in the application that do not use CXF (there's one
>> that uses ajax 1.3, and another using jersey. This configuration worked
>> in the pre-maven implementation and I think there may be some clash of
>> dependencies. Filtering out all the proprietary and homegrown stuff we
>> use, these are the jars used by the application, maybe someone can
>> suggest where the conflict may lie.
>>
>> One probably unrelated problem: Why is servlet-api-6.0.20.jar being
>> packaged? I explicitly defined this dependency as "provided".
>>
>> XmlSchema-1.4.5.jar
>> activation-1.1.jar
>> antlr-2.7.6.jar
>> asm-1.5.3.jar
>> asm-attrs-1.5.3.jar
>> axis-1.3.jar
>> axis-jaxrpc-1.3.jar
>> c3p0-0.9.1.2.jar
>> cglib-2.1_3.jar
>> commons-collections-3.2.1.jar
>> commons-discovery-0.2.jar
>> commons-lang-2.4.jar
>> commons-logging-1.0.4.jar
>> cxf-api-2.2.5.jar
>> cxf-common-schemas-2.2.5.jar
>> cxf-common-utilities-2.2.5.jar
>> cxf-rt-bindings-soap-2.2.5.jar
>> cxf-rt-bindings-xml-2.2.5.jar
>> cxf-rt-core-2.2.5.jar
>> cxf-rt-databinding-jaxb-2.2.5.jar
>> cxf-rt-frontend-jaxws-2.2.5.jar
>> cxf-rt-frontend-simple-2.2.5.jar
>> cxf-rt-transports-http-2.2.5.jar
>> cxf-rt-transports-http-jetty-2.2.5.jar
>> cxf-rt-ws-addr-2.2.5.jar
>> cxf-tools-common-2.2.5.jar
>> dom4j-1.6.1.jar
>> ehcache-1.2.3.jar
>> geronimo-activation_1.1_spec-1.0.2.jar
>> geronimo-annotation_1.0_spec-1.1.1.jar
>> geronimo-javamail_1.4_spec-1.6.jar
>> geronimo-jaxws_2.1_spec-1.0.jar
>> geronimo-stax-api_1.0_spec-1.0.1.jar
>> geronimo-ws-metadata_2.0_spec-1.1.2.jar
>> hibernate-3.2.7.ga.jar
>> jaxb-api-2.0.jar
>> jaxb-impl-2.0.5.jar
>> jersey-client-1.1.2-ea.jar
>> jersey-core-1.1.2-ea.jar
>> jetty-6.1.21.jar
>> jetty-util-6.1.21.jar
>> jsr173_api-1.0.jar
>> jsr311-api-1.1.jar
>> jta-1.0.1B.jar
>> junit-4.7.jar
>> log4j-1.2.15.jar
>> mysql-connector-java-5.1.10.jar
>> neethi-2.0.4.jar
>> oro-2.0.8.jar
>> saaj-api-1.3.jar
>> saaj-impl-1.3.2.jar
>> servlet-api-6.0.20.jar
>> slf4j-api-1.5.8.jar
>> slf4j-jdk14-1.5.8.jar
>> spring-beans-2.5.5.jar
>> spring-context-2.5.5.jar
>> spring-core-2.5.5.jar
>> velocity-1.6.2.jar
>> velocity-tools-1.4.jar
>> wsdl4j-1.6.2.jar
>> wstx-asl-3.2.9.jar
>> xml-resolver-1.2.jar
>>
>> Steve Cohen wrote:
>>> I think we are getting closer to the core of the problem. But I've
>>> eliminated all the ideas we had up to now.
>>>
>>> Versioning: I enabled -xjc-mark-generated and now all objects show this
>>> as you indicated they should:
>>>
>>> @Generated(value = "com.sun.tools.xjc.Driver", date =
>>> "2010-01-21T01:33:43-06:00", comments = "JAXB RI
>>> vhudson-jaxb-ri-2.1-833")
>>>
>>> I excluded the geronimo-servlet_2.5_spec dependency although that is
>>> unneeded under Tomcat as you had indicated. That had nothing to do with
>>> the problem either.
>>>
>>> Then I took a hard look at the error messages:
>>>
>>> They are of the form: "There's no ObjectFactory with an @XmlElementDecl"
>>>
>>> I compared that with the generated sources:
>>>
>>> @XmlElementRef(name = "activatedtime", type = JAXBElement.class)
>>>
>>> It's looking for @XmlElementDecls and all it has are @XmlElementRefs.
>>>
>>> To repeat, here are my "extraargs":
>>>
>>> <extraargs>
>>> <extraarg>-p</extraarg>
>>> <extraarg>com.dashcs.api.service.emerg</extraarg>
>>> <extraarg>-impl</extraarg>
>>> <extraarg>-client</extraarg>
>>> <extraarg>-verbose</extraarg>
>>> <extraarg>-xjc-mark-generated</extraarg>
>>> </extraargs>
>>>
>>> Daniel Kulp wrote:
>>>> On Thu January 21 2010 12:08:16 pm Steve Cohen wrote:
>>>>> Daniel Kulp wrote:
>>>>>> On Wed January 20 2010 11:41:08 am Steve Cohen wrote:
>>>>>>> A CXF-based client that worked under cxf 2.0.7 fails when it is built
>>>>>>> under cxf 2.1.8 with IllegalAnnotationExceptions.
>>>>>> First off, if updating, I definitely suggest going to 2.2.5 (or 2.2.6
>>>>>> on Monday). 2.1.9 which will be released by Monday will be the last
>>>>>> version of 2.1.x that we release. Thus, moving up to 2.2.x now would
>>>>>> be a good thing if you're starting a migration anyway.
>>>>>>
>>>>>>> The code generated from the wsdl seems identical so that's not the
>>>>>>> problem.
>>>>>> That's probably a problem. If the code is identical, it SOUNDS like
>>>>>> you are picking up the older version of the code generator. There
>>>>>> definitely should be some changes like XmlSeeAlso annotations and
>>>>>> likely changes in the ObjectFactory and package-info.java classes.
>>>>>> Definitely check the comments in the jaxb generated classes to make
>>>>>> sure they have a 2.1.12 version number for the version of jaxb that
>>>>>> generated them.
>>>>> Daniel, can you please be more specific what you mean about the 2.1.12
>>>>> version number. I see no version numbers in either set of generated
>>>>> code.
>>>> Sorry. My bad. The example that I had looked at that DID have version
>>>> numbers in it had passed the "-mark-generated" generated flag into the
>>>> XJC which then generated new annotations on the classes that had a JAXB
>>>> version number in it. You could add -xjc-mark-generated to your
>>>> extraargs to do the same just to be sure. It should say something
>>>> like:
>>>>
>>>> @Generated(value = "com.sun.tools.xjc.Driver", date =
>>>> "2010-01-21T12:25:02-05:00", comments = "JAXB RI
>>>> vhudson-jaxb-ri-2.1-833")
>>>>
>>>>
>>>> Is there anyway you could create small example that reproduces the
>>>> error? Just runs the codegen plugin and then creates a client? Doesn't
>>>> need to hit a server or anything I'm assuming. The main thing is to
>>>> check the generated ObjectFactory class to make sure it has the correct
>>>> @XmlElementDecl annotated stuff.
>>>>
>>>>> (Incidentally,
>>>>> is there a standard cxf guideline for the minimum runtime dependencies
>>>>> needed merely to run generated code on the client side?)
>>>> See:
>>>>
>>>> http://svn.apache.org/repos/asf/cxf/trunk/distribution/src/main/release/
>>>> lib/WHICH_JARS
>
