[
https://issues.apache.org/jira/browse/CXF-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034657#comment-13034657
]
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: https://issues.apache.org/jira/browse/CXF-3523
> 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: http://www.atlassian.com/software/jira
