
|
If you were logged in you would be able to see more operations.
|
|
|
XFire
Created: 19/Jul/06 09:34 AM
Updated: 20/Jul/06 01:36 PM
|
|
| Component/s: |
Spring
|
| Affects Version/s: |
1.1.2
|
| Fix Version/s: |
1.2-RC
|
|
Michael Vorburger to user on Jul 10:
Are we getting Spring usage all wrong, or does the XFireClientFactoryBean indeed feel quite "odd" to configure if set up with an JAXWSServiceFactory (or AnnotationServiceFactory/subclass) ? Because:
- wsdlDocumentUrl should probably not be required IFF serviceFactory instanceof AnnotationServiceFactory (it complains if you do not give it a WSDL)
- serviceName and namespace can be read from e.g. JAX-WS Annotations... but in order for that to happen, and not require a WSDL to be available at runtime for the XFireClientFactoryBean to find them there, you have to SET the serviceName and namespace to some dummy value so that they are NOT read from the WSDL, and then in AnnotationServiceFactory.create(final Class clazz, String name, String namespace, Map properties) from the Annotations (ignoring name and namespace parameters).
- serviceClass can not be a Java interface... but wouldn't that make sense when using with an AnnotationServiceFactory, where serviceName and namespace can be found on the interface? The "real" implementation is in another module and not available in my scenario. As a work-around we are specifying that auto-generated *Impl for serviceClass, the one from wsgen with UnsupportedOperationException... (BTW: Is generating that useless class, with all annotations
duplicated, required by JAX-WS Spec or something? We find it confusing and would prefer wsgen not to generate that *Impl at all.)
- completely unrelated: finding the service Endpoint URL by chopping off ?wsdl from the WSDL URL, in getServiceUrl(), unless you set the URL property, is probably not what one would expect? We had assumed it reads the endpoint URL from the wsdl:service/wsdl:port/soap:address.
Regards,
Michael Vorburger, IPT.ch
PS: This is more feedback than an actual call for help...
Fried Hoeben to user on Jul 11:
I have to admit the XFireClientFactoryBean really was originally developed based as a helper when using Aegis. Later support for things like the serviceClass was added (the serviceInterface is the property where one would set an interface) so that other factories became usable.
But maybe it would make more sense to have a special ...FactoryBean to deal with the scenario you are looking at. Similar features, but tailored to what is needed in this case. A patch is welcome 
Also the approach of getting the service URL from the WSDL content seems like a better solution. A Jira issue and possibly a patch are welcome.
Fried
Dan Diephouse to to user on Jul 12:
Agreed. If someone could at least file a JIRA issue for this, it would help speed things along. A patch even more so .
|
|
Description
|
Michael Vorburger to user on Jul 10:
Are we getting Spring usage all wrong, or does the XFireClientFactoryBean indeed feel quite "odd" to configure if set up with an JAXWSServiceFactory (or AnnotationServiceFactory/subclass) ? Because:
- wsdlDocumentUrl should probably not be required IFF serviceFactory instanceof AnnotationServiceFactory (it complains if you do not give it a WSDL)
- serviceName and namespace can be read from e.g. JAX-WS Annotations... but in order for that to happen, and not require a WSDL to be available at runtime for the XFireClientFactoryBean to find them there, you have to SET the serviceName and namespace to some dummy value so that they are NOT read from the WSDL, and then in AnnotationServiceFactory.create(final Class clazz, String name, String namespace, Map properties) from the Annotations (ignoring name and namespace parameters).
- serviceClass can not be a Java interface... but wouldn't that make sense when using with an AnnotationServiceFactory, where serviceName and namespace can be found on the interface? The "real" implementation is in another module and not available in my scenario. As a work-around we are specifying that auto-generated *Impl for serviceClass, the one from wsgen with UnsupportedOperationException... (BTW: Is generating that useless class, with all annotations
duplicated, required by JAX-WS Spec or something? We find it confusing and would prefer wsgen not to generate that *Impl at all.)
- completely unrelated: finding the service Endpoint URL by chopping off ?wsdl from the WSDL URL, in getServiceUrl(), unless you set the URL property, is probably not what one would expect? We had assumed it reads the endpoint URL from the wsdl:service/wsdl:port/soap:address.
Regards,
Michael Vorburger, IPT.ch
PS: This is more feedback than an actual call for help...
Fried Hoeben to user on Jul 11:
I have to admit the XFireClientFactoryBean really was originally developed based as a helper when using Aegis. Later support for things like the serviceClass was added (the serviceInterface is the property where one would set an interface) so that other factories became usable.
But maybe it would make more sense to have a special ...FactoryBean to deal with the scenario you are looking at. Similar features, but tailored to what is needed in this case. A patch is welcome 
Also the approach of getting the service URL from the WSDL content seems like a better solution. A Jira issue and possibly a patch are welcome.
Fried
Dan Diephouse to to user on Jul 12:
Agreed. If someone could at least file a JIRA issue for this, it would help speed things along. A patch even more so  . |
Show » |
|