cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Ruiz (JIRA)" <>
Subject [jira] [Commented] (CXF-3523) Ability to force java2wsdl approach for javaws:client even if wsdlLocation is set (via populateFromClass property or, at least, custom jaxws:serviceFactory) when using spring integration
Date Tue, 17 May 2011 09:49:47 GMT


Albert Ruiz commented on CXF-3523:

I think yesterday I was a little ofuscated by ServiceContractResolverRegistry (until I found
the workaround to server endpoints setting populateFromClass=true although wsdlLocation being
set because of ServiceContractResolver on client endpoints on same context). 

Now that I have thought it over again, I see that on client side it has no sense to do java2wsdl
if ServiceContractResolver is present; wsdlLocation is not the actual location of the server
endpoint, just the wsdl. So if I'm using a ServiceContractResolverRegistry on client endpoints
(no matter my only reason is to know the server address), the reasonable thing is to process
this wsdl completely and don't build service model from java.

¿is this argumentation correct? (Sorry for the lost time :( ).

Right now, my conclusion is that the issue is another one (althought there's a workaround
as i said). There's the need to be able to configure ServiceContractResolverRegistry to only
work with client endpoints and not server ones (not in all cases, just the ability to configure
it). Otherwise, a dead end can be reached when using java2wsdl for server endpoints:
   1.- A ServiceContractResolverRegistry is configured for client endpoints to get wsdl location.
   2.- There are server endpoints on same application context.
   3.- This same ServiceContractResolverRegistry will be used during initialization of server
endpoints on same application context. This initilialization will fail if the registry already
has the wsdl location statically for these endpoints (other client endpoints for other applications
may need this wsdl location), because ServiceContractResolver will set wsdlLocation and service
model building from wsdl will be triggered. This building will fail, since wsdl doesn't exist
yet! (it's what server endpoint should be initializing at this moment!).
  As I said, the workaround for me is to set a custom serviceFactory with populateFromClass=true.
But this is not really what should be done, since I think no ServiceContractResolver at all
should be used for server endpoints in this case (I only want it for client endpoints).

¿is this correct? ¿do i close this issue and open a new one?

> Ability to force java2wsdl approach for javaws:client even if wsdlLocation is set (via
populateFromClass property or, at least, custom jaxws:serviceFactory) when using spring integration
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: CXF-3523
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: Configuration
>    Affects Versions: 2.2.12, 2.4, 2.3.4
>            Reporter: Albert Ruiz
>            Priority: Minor
> To put into context: There's "no way" (i think there's one using some spring 'tricks')
of using java2wsdl with client endpoints along with ServiceContractResolver functionality
(to access an UDDI registry, for example). When using ServiceContractResolver, the wsdlLocation
property gets updated, and this property is later used to determine the approach to use when
initializing the service model. The same occurs with server endpoints but, at least, a custom
jaxws:serviceFactory can be configured with populateFromClass set to true (this flag is checked
when deciding how to initialize the model).
> ¿Is there a reason for jaxws:client not having the ability to pass a custom serviceFactory
like server does? If there's a good reason for that (it seems to me that maybe this is done
voluntarily) ¿couldn't a populateFromClass property be added to jaxws:client and jaxws:server
to handle this when instantiating the default serviceFactory?

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message