[ 
https://issues.apache.org/jira/browse/CXF-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034625#comment-13034625
 ] 

Albert Ruiz commented on CXF-3523:
----------------------------------

The problem is that there are cases where wsdlLocation is set not empty at 
runtime, being one of them the use of ServiceContractResolverRegistry (maybe 
it's the only one, i don't know) to lookup the server endpoint (for example 
from a UDDI Registry), with which the client endpoint proxy must connect. 
ServiceContractResolverRegistry sets wsdlLocation dynamically always, and so 
the model is build from wsdl and not from java. In my case, there's a need to 
know from an UDDI registry where the server endpoint is located, but the 
service model still would be better if it could be builded from java, as all 
this info is already present in classpath.

> 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

Reply via email to