cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: IllegalAnnotationExceptions when cxf client is ported from 2.0.7 to 2.1.8
Date Fri, 22 Jan 2010 13:25:35 GMT
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
> 


Mime
View raw message