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 Sat, 23 Jan 2010 00:24:46 GMT
At last!

The final roadblock was a 7k cxf-rt-core-2.2.5.jar that some way some
how got downloaded to my repository from somewhere instead of the proper
389.3 Kb one.  This, of course, did not contain any
org.apache.cxf.bus.CXFBusFactory class.

Not sure how such a thing could happen, and it was a mixture of luck and
perseverence that led me there.  I went to look in the jar to see if the
class was there for lack of anything better to do, and thought, that
doesn't look right.  I deleted it and all was well.  Does some
repository have junk in it or did it have junk in it at some point in
the past?




Steve Cohen wrote:
> 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