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 >> >> > > >
