Thanks Dan,
Before I saw your note I had already started creating an example project that shows the problem. I submitted the example project and bug to JIRA: http://jira.codehaus.org/browse/XFIRE-914 Strangely enough, I could not replicate the error that occurs on deployment (not sure why), but I was able to demonstrate the wrong namespace being applied to the wrapper elements in the SOAP messages. Thanks so much for looking at this! It is very much appreciated! -Chris -----Original Message----- From: Dan Diephouse [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 3:03 PM To: [email protected] Subject: Re: [xfire-user] A Couple of XFire 1.2.5 Bugs w/ WSDL-first services? Chris: These are definitely legitimate. Thanks for investigating this. I consider this a critical problem and I am working to get 1.2.6 cut by Sunday. I screwed things up last minute on the 1.2.5 release. Many apologies, and we'll get this fixed ASAP! - Dan On 3/15/07, Christopher Moesel <[EMAIL PROTECTED]> wrote: So are these then legitimate bugs that I should file in JIRA? Has anyone successfully done what I described below in XFire 1.2.5? - create a wsdl-first service using JAXWSServiceFactory - create a wsdl-first service with schema types defined in a separate namespace? -Chris -----Original Message----- From: Christopher Moesel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 3:47 PM To: [email protected] Subject: [xfire-user] A Couple of XFire 1.2.5 Bugs w/ WSDL-first services? OK-just converted my implementation to use the new interface generated by XFire 1.2.5. Overall, refactoring the API implementation wasn't too bad. But I ran into a few issues that I haven't been able to resolve. This is a WSDL-first service. It uses one namespace (http://mycompany.com/myservice) for the soap message definitions, operation definitions, etc, and another namespace (http://mycompany.com/myservice/types) for all of the types defined in the XML Schema. Running in Tomcat 5.5 on JDK5. ISSUE #1: I am using a Spring configuration. I was using the JAXWSServiceFactory as showcased in the jaxws-spring example in the XFire distribution: <bean name="xfire.jaxwsServiceFactory" class="org.codehaus.xfire.jaxws.JAXWSServiceFactory"> <constructor-arg ref="xfire.transportManager" /> </bean> <bean name="MyService" class="org.codehaus.xfire.spring.ServiceBean"> <!-serviceBean, serviceClass, wsdlURL, and handlers go here --> <property name="serviceFactory"> <ref bean="xfire.jaxwsServiceFactory" /> </property> </bean> This worked perfectly in 1.2.4. But in 1.2.5, it fails on startup. I get an XFireRuntimeException, caused by a NullPointerException: org.codehaus.xfire.XFireRuntimeException: Couldn't load provider.. Nested exception is java.lang.NullPointerException: null java.lang.NullPointerException at org.codehaus.xfire.jaxb2.JaxbTypeCreator.isJaxbType(JaxbTypeCreator.java :92) at org.codehaus.xfire.jaxws.type.JAXWSTypeCreator.createTypeForClass(JAXWST ypeCreator.java:31) at org.codehaus.xfire.jaxws.type.JAXWSTypeCreator.createHolderType(JAXWSTyp eCreator.java:51) at org.codehaus.xfire.aegis.type.AbstractTypeCreator.createTypeForClass(Abs tractTypeCreator.java:101) at org.codehaus.xfire.jaxws.type.JAXWSTypeCreator.createTypeForClass(JAXWST ypeCreator.java:38) ... plenty more stack trace available if anyone wants it ... ISSUE #2: Since that failed, I opted to try using the JaxbServiceFactory instead (since this is the ServiceFactory used in the generated services.xml file, and since I had also successfully tested using this factory in 1.2.4). I configured it like so (and changed the appropriate reference in the service bean): <bean name="xfire.jaxb2ServiceFactory" class="org.codehaus.xfire.jaxb2.JaxbServiceFactory"> <constructor-arg ref="xfire.transportManager" /> </bean> Again, this worked in 1.2.4. In 1.2.5, it appears to deploy fine (hurray!). But when my test clients try to interact with it, I notice a problem: The wrapper element of the response (the first element under the soap:Body) is in the wrong namespace! Instead of being in the http://mycompany.com/myservice/types namespace, it is in the http://mycompany.com/myservice namespace (which is the namespace of the soap messages, operations, etc). If I look at the generated ObjectFactory class, I note that in the private final static QName section at the top, the namespace in the QName is right: private final static QName _MyOperationResponse_QNAME = new QName("http://mycompany.com/myservice/types";, "MyOperationResponse"); Likewise, if I look at the methods at the bottom of the class, the namespace in the annotations appears correct as well: @XmlElementDecl(namespace = "http://mycompany.com/myservice/types ", name = "MyOperationResponse") public JAXBElement<MyOperationResponseType> createMyOperationResponse(MyOperationResponseType value) { return new JAXBElement<MyOperationResponseType>(_MyOperationResponse_QNAME, MyOperationResponseType.class, null, value); } But, as mentioned above, the returned soap response uses the namespace: http://mycompany.com/myservice. ISSUE #3: I attempted to build the jaxws-spring example in the 1.2.5 distribution, but the build failed. I was using the command "mvn -e install". Here is the beginning of the stack trace I got from the log file: ------------------------------------------------------------------------ ------- Test set: org.something.services.hello.test.HelloServiceTestCase ------------------------------------------------------------------------ ------- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec <<< FAILURE! warning(junit.framework.TestSuite$1) Time elapsed: 0 sec <<< FAILURE! junit.framework.AssertionFailedError: Exception in constructor: testViaXFireServer (org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hello.client' defined in class path resource [client.beans.xml]: Initialization of bean failed; nested exception is java.lang.IllegalArgumentException: URI is not absolute java.lang.IllegalArgumentException: URI is not absolute at java.net.URI.toURL(URI.java:1080) at org.codehaus.xfire.spring.remoting.XFireClientFactoryBean.makeClient(XFi reClientFactoryBean.java:504) at org.codehaus.xfire.spring.remoting.XFireClientFactoryBean.createClient(X FireClientFactoryBean.java:412) at org.codehaus.xfire.spring.remoting.XFireClientFactoryBean.afterPropertie sSet(XFireClientFactoryBean.java:119) ... more stack trace available if anyone wants/needs it ... Hopefully these are easy problems to fix (or hopefully I'm just doing something wrong)... if not, I may have to go back to 1.2.4 (and roll back my API changes). Thanks! Chris -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
