Dan,
Sweet!!! It worked! I added the following nasty hack to the client that
is called prior to the service client setup:
System.clearProperty("java.protocol.handler.pkgs");
Hopefully that won't interfere with anything else. Would be nice if
there was a way to audit what classes are setting System properties, so
I could find out what is setting it. I bet that request would go over
like a ton of bricks though. :) (I have my suspicions that it is pluto
1.0.1, but it may have just been a concidence that I got a transient
error after removing this property.)
Thanks!!!
Gary
Daniel Kulp wrote:
Never seen this one before. I did a quick google and found:
http://forum.java.sun.com/thread.jspa?threadID=397291&messageID=1739246
It looks like a strange system property is affecting it. Not sure
where that would be coming from.
Dan
On Jul 1, 2008, at 4:50 PM, Gary Weaver wrote:
Dan,
Awesome! That got past that issue. I got the *Port constant as the
QName from the autogenerated service class and set it like:
QName portName = MyService.MyServicePort;
String bindingId = SOAPBinding.SOAP11HTTP_BINDING;
String endpointAddress = getEndpoint();
service.addPort(portName, bindingId, endpointAddress);
It worked fine locally.
My development environment where is works is using OS X and:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-120, mixed mode, sharing)
The test server is using CentOS and:
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_10-b03, mixed mode)
Here is the specific error I'm getting now on the test server (using
Apache CXF v2.1.1) that I don't get in development:
java.lang.ClassCastException:
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
at
org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:129)
at
org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:480)
at
org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
at ... (autogenerated client service method)
at ...
I see a message from last year referring to a similar problem (even
though I'm having this issue inside Tomcat instead of Weblogic):
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01949.html
Thanks in advance for any help you can provide,
Gary
Daniel Kulp wrote:
Oh. Hmm...
You might need to do:
service.addPort(QName portName, String bindingId, String
endpointAddress)
before calling getPort(...) with the appropriate portName and the
appropriate SOAPBinding.SOAP11HTTP_BINDING binding type (assuming
SOAP 1.1) and you can put the endpoint address right there and not
do the BindingProvider thing.
Dan
On Jul 1, 2008, at 2:41 PM, Gary Weaver wrote:
Thanks, Dan!
After doing that and creating my service similar to:
MyService service = new MyService(null);
I'm getting a new error (generified namespace and service port name):
javax.xml.ws.WebServiceException: Port
{http://somehost/target/namespace/goes/here}name_of_service_port
not found.
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:243)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:234)
at javax.xml.ws.Service.getPort(Service.java:92)
I also tried:
MyService service = new MyService(null, null);
But that didn't make any difference.
As a sanity check, I changed it back to using default constructor
and that works locally (since the WSDL is grabbed local via file
URL). So it is definitely something about specifying it with null
that causes a problem.
Any help as always is much appreciated.
Thanks!
Gary
Daniel Kulp wrote:
If the code is generated from a "correct" WSDL, then you don't
really need the WSDL at all at runtime. You can specify a "null"
URL for the wsdl in the constructor. The runtime will then use
the annotations that the code generator added to the code for
everything it needs.
The exception to that is the actual URL that is hit. That is not
recorded in the annotations. However, that's settable via
standard JAX-WS API's:
((BindingProvider)portType).getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_URL, "https://blah/blah/blah");
Dan
On Jul 1, 2008, at 1:31 PM, Gary Weaver wrote:
One sidenote and also a big thanks to Dan and Glen for their
comments!:
Even though I'm just trying to get over this issue by specifying
the WSDL on the service and trying to get the call to get that
WSDL to deal with the non-matching CN on the certificate, I just
want to clarify that the heart of the issue is not really in CXF
or its wsdl2java, but that the service I'm dealing with stinks -
the WSDL it generates and hosts has a bad endpoint, has the wrong
namespace defined for the response (it doesn't match what comes
back), and I'm forced to use a hostname (cname) for the server
that doesn't match the server certificate. So far, CXF has helped
me overcome all of those issues when I test the client locally
with a local WSDL. I really wish that there would be some way to
keep the client from having to access the WSDL at all (since I've
customized the WSDLs for the services I'm integrating with by
changing the response namespace to match what comes back, and
don't really feel the need or responsibility to host the modified
WSDLs on a webserver). But, worst case, I can host the WSDL on a
separate webserver if needed. However, any ideas for having to
avoid that would be appreciated.
Thanks,
Gary
Gary Weaver wrote:
Ok, it looks like you can override the WSDL in the constructor
of the autogenerated service object, like:
String wsdlUrl =
"https://somehost:someport/path/to/the/wsdl/MyService.wsdl";
MyService service = new MyService(new URL(wsdlUrl));
However, that let me to a new problem:
junit.framework.AssertionFailedError: error:
javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:134)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65)
at javax.xml.ws.Service.<init>(Service.java:56)
at ... (autogenerated client code)
at ...
Caused by:
org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:83)
at
org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:140)
at
org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:132)
... 31 more
Caused by: javax.wsdl.WSDLException: WSDLException:
faultCode=PARSER_ERROR: Problem parsing
'https://somehost:someport/path/to/the/wsdl/MyService.wsdl'.:
java.io.IOException: HTTPS hostname wrong: should be
<somehost:someport>
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:206)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:170)
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
... 33 more
Caused by: java.io.IOException: HTTPS hostname wrong: should be
<somehost:someport>
at
sun.net.www.protocol.https.HttpsClient.checkURLSpoofing(HttpsClient.java:490)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:415)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292)
...
This error occurs when the wsdl URL's hostname does not match
the Common Name (CN) on the server certificate.
I'm already doing the following which combatted the issue
previously when I was using a local WSDL file and wasn't having
to use HTTPS to get access to it:
Client client = ClientProxy.getClient(portType);
HTTPConduit conduit = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
TLSClientParameters params = conduit.getTlsClientParameters();
if (params == null) {
params = new TLSClientParameters();
conduit.setTlsClientParameters(params);
}
// NOTE! ONLY DO THIS FOR TESTING, NOT PRODUCTION!
// this is to get around the error:
// The https URL hostname does not match the Common Name
(CN) on the server certificate. To disable this check (NOT
recommended for production) set the CXF client TLS configuration
property "disableCNCheck" to true.
params.setDisableCNCheck(true);
However, now that I'm accessing the WSDL via HTTPS, it would
appear that there should be some mechanism to allow me to tell
the client to not crap out (disable the CN check) for the get
WSDL over HTTPS check in addition to the actual service usage call.
Unfortunately I'm at a loss for how to do that.
Thanks in advance for any help you can provide,
Gary
Gary Weaver wrote:
Hello again,
Anyone know why the client code generated by cxf-codegen-plugin
v2.1 + JAXB is hardcoding the original WSDL file's path into
the client classes, and then looking for that file when the
client is used?
Any idea how to keep it from doing that?
For example, in one of the autogenerated client service classes
it has a static block that looks like:
...
static {
URL url = null;
try {
url = new
URL("file:/path/to/my/project/trunk/src/main/wsdl/MyService.wsdl");
} catch (MalformedURLException e) {
System.err.println("Can not initialize the default wsdl
from
file:/path/to/my/project/trunk/src/main/wsdl/MyService.wsdl");
// e.printStackTrace();
}
WSDL_LOCATION = url;
}
...
And in the pom.xml looks like:
...
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>checklist</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/wsdl/MyService.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
...
</executions>
</plugin>
...
And the error that occurs when you run this in an environment
where that path/file
(/path/to/my/project/trunk/src/main/wsdl/MyService.wsdl)
doesn't exist is:
javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:134)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65)
at javax.xml.ws.Service.<init>(Service.java:56)
at ... (autogenerated client code)
at ...
Caused by:
org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:83)
at
org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:140)
at
org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:132)
...
Caused by: javax.wsdl.WSDLException: WSDLException:
faultCode=PARSER_ERROR: Problem parsing
'file:/path/to/my/project/trunk/src/main/wsdl/MyService.wsdl'.:
java.io.FileNotFoundException:
/path/to/my/project/trunk/src/main/wsdl/MyService.wsdl (No such
file or directory)
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:206)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:170)
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
...
Caused by: java.io.FileNotFoundException:
/path/to/my/wsdl/MyService.wsdl (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown
Source)
at
org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown
Source)
at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown
Source)
...
Thanks in advance!
Gary
--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University