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( JAXWSTypeCreator.java:31) at org.codehaus.xfire.jaxws.type.JAXWSTypeCreator.createHolderType( JAXWSTypeCreator.java:51) at org.codehaus.xfire.aegis.type.AbstractTypeCreator.createTypeForClass( AbstractTypeCreator.java:101) at org.codehaus.xfire.jaxws.type.JAXWSTypeCreator.createTypeForClass( JAXWSTypeCreator.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( XFireClientFactoryBean.java:504) at org.codehaus.xfire.spring.remoting.XFireClientFactoryBean.createClient( XFireClientFactoryBean.java:412) at org.codehaus.xfire.spring.remoting.XFireClientFactoryBean.afterPropertiesSet (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
