History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XFIRE-538
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Dan Diephouse
Reporter: Michael Vorburger
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
XFire

XFireClientFactoryBean "oddities" (when used with JAXWSServiceFactory or other AnnotationServiceFactory)

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

Time Tracking:
Not Specified


 Description  « Hide
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 .



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Dan Diephouse - 20/Jul/06 01:00 PM
OK, I think I've resolved all these issues except for the endpoint url issue. Its checked into SVN now if you want to look at it.

Dan Diephouse - 20/Jul/06 01:36 PM
I went ahead and changed the url stuff as well. It first tries to get the URL from the WSDL if specified. Otherwise it fallsback to the service url property.