Hi,
I'm not sure if it can help but there's a ServiceContractResolver interface
available in CXF
public interface ServiceContractResolver {
URI getContractLocation(QName qname);
}
So if you have a custom cxf configuration file which would register a ServiceContractResolver bean then in a client code you can
simply do
new GreeterService(null, GREETER_QNAME)
and your ServiceContractResolver will be checked.
I'm not sure if wsdltojava can generate such code for you though...If this option works for you then may be you can modify the
generated code or open a JIRA and request an enhancement for wsdltojava
Cheers, Sergey
Hello Dan, thanks for reply, I've tried 'classpath:my.wsdl' or
'classpath:/my.wsdl' as wsdlLocation param to wsdl2java. The static
initializer url = new java.net.URL("classpath:my.wsdl"); in generated
Service class throws a MalFormed exception. The only way I've managed to get
the URL() constructor to find my.wsdl is when i specify a 'file' scheme such
as 'file:my.wsdl', then the URL constructor finds the file but it has to be
relative to the starting directory of the jvm(not embedded in a jar). I
figured if code generation in wsdl2java could recognize 'classpath:' scheme
in wsdlLocation param and generate url =
Service.class.getClassLoader().getResource("my.wsdl"); instead of try { url
= new URL("my.wsdl"); } catch (MalformedURLException e) { } then runtime
should find wsdl from classpath since java.net.URL constructor won't.
--
View this message in context:
http://www.nabble.com/can-I-specify-classpath-for-wsdllocation-param-to-wsdl2java--tp20258375p20270757.html
Sent from the cxf-user mailing list archive at Nabble.com.
