[ 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