[
https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888557#comment-16888557
]
Karl Wright edited comment on CONNECTORS-1566 at 7/19/19 6:22 AM:
------------------------------------------------------------------
So, here's where things stand.
(1) The checked in code builds a connector jar that properly includes a
META-INF section that has a jax-ws-catalog.xml and all the wsdls, but they
don't seem to get picked up.
(2) For standard HTTP access, the code that is checked in nevertheless works,
because the wsdls are simply accessed from the server with the ?wsdl addition
to the URL as a fallback. This automatically is done in the Java JDK class
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.
(3) The user I've been developing for can ONLY use this with SSL. I've checked
in code which sets the BindingProvider
"com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory" property to
establish the right SSLSocketFactory. Unfortunately, everything I've read
indicates that this does not work with server-fetched wsdls, because the code
that sets the property happens AFTER the constructor for the service. See code
snippet below.
{code}
try {
this.authService = new Authentication_Service(new
URL(authenticationServiceURL));
this.documentManagementService = new DocumentManagement_Service(new
URL(documentManagementServiceURL));
this.contentServiceService = new ContentService_Service(new
URL(contentServiceServiceURL));
this.memberServiceService = new MemberService_Service(new
URL(memberServiceServiceURL));
this.searchServiceService = new SearchService_Service(new
URL(searchServiceServiceURL));
} catch (javax.xml.ws.WebServiceException e) {
throw new ManifoldCFException("Error initializing web services:
"+e.getMessage(), e);
} catch (MalformedURLException e) {
throw new ManifoldCFException("Malformed URL: "+e.getMessage(), e);
}
// Initialize authclient etc.
this.authClientHandle = authService.getBasicHttpBindingAuthentication();
this.documentManagementHandle =
documentManagementService.getBasicHttpBindingDocumentManagement();
this.contentServiceHandle =
contentServiceService.getBasicHttpBindingContentService();
this.memberServiceHandle =
memberServiceService.getBasicHttpBindingMemberService();
this.searchServiceHandle =
searchServiceService.getBasicHttpBindingSearchService();
// Set up endpoints
((BindingProvider)authClientHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
authenticationServiceURL);
((BindingProvider)documentManagementHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
documentManagementServiceURL);
((BindingProvider)contentServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
contentServiceServiceURL);
((BindingProvider)memberServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
memberServiceServiceURL);
((BindingProvider)searchServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
searchServiceServiceURL);
// Set SSLSocketFactory's
if (sslSocketFactory != null) {
((BindingProvider)authClientHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)documentManagementHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)contentServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)memberServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)searchServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
}
{code}
So now we're apparently *forced* to figure out how to get runtime access to
wsdls we ship work, because the fallback won't work for SSL.
In the absence of somebody who understands this stuff well enough to advise us,
we have two choices. First choice is to use a different supported transport
than the standard one. I recall reading that CXF's "async" transport used
commons/httpclient, which I know a lot more about and would have a much better
chance of configuring for our needs. The second choice is to find out how
people do SSL with the ?wsdl fallback make this work; there must be a way, no?
See:
https://stackoverflow.com/questions/11001102/how-to-programmatically-set-the-sslcontext-of-a-jax-ws-client
was (Author: kwri...@metacarta.com):
So, here's where things stand.
(1) The checked in code builds a connector jar that properly includes a
META-INF section that has a jax-ws-catalog.xml and all the wsdls, but they
don't seem to get picked up.
(2) For standard HTTP access, the code that is checked in nevertheless works,
because the wsdls are simply accessed from the server with the ?wsdl addition
to the URL as a fallback. This automatically is done in the Java JDK class
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.
(3) The user I've been developing for can ONLY use this with SSL. I've checked
in code which sets the BindingProvider
"com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory" property to
establish the right SSLSocketFactory. Unfortunately, everything I've read
indicates that this does not work with server-fetched wsdls, because the code
that sets the property happens AFTER the constructor for the service. See code
snippet below.
{code}
try {
this.authService = new Authentication_Service(new
URL(authenticationServiceURL));
this.documentManagementService = new DocumentManagement_Service(new
URL(documentManagementServiceURL));
this.contentServiceService = new ContentService_Service(new
URL(contentServiceServiceURL));
this.memberServiceService = new MemberService_Service(new
URL(memberServiceServiceURL));
this.searchServiceService = new SearchService_Service(new
URL(searchServiceServiceURL));
} catch (javax.xml.ws.WebServiceException e) {
throw new ManifoldCFException("Error initializing web services:
"+e.getMessage(), e);
} catch (MalformedURLException e) {
throw new ManifoldCFException("Malformed URL: "+e.getMessage(), e);
}
// Initialize authclient etc.
this.authClientHandle = authService.getBasicHttpBindingAuthentication();
this.documentManagementHandle =
documentManagementService.getBasicHttpBindingDocumentManagement();
this.contentServiceHandle =
contentServiceService.getBasicHttpBindingContentService();
this.memberServiceHandle =
memberServiceService.getBasicHttpBindingMemberService();
this.searchServiceHandle =
searchServiceService.getBasicHttpBindingSearchService();
// Set up endpoints
((BindingProvider)authClientHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
authenticationServiceURL);
((BindingProvider)documentManagementHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
documentManagementServiceURL);
((BindingProvider)contentServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
contentServiceServiceURL);
((BindingProvider)memberServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
memberServiceServiceURL);
((BindingProvider)searchServiceHandle).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
searchServiceServiceURL);
// Set SSLSocketFactory's
if (sslSocketFactory != null) {
((BindingProvider)authClientHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)documentManagementHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)contentServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)memberServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
((BindingProvider)searchServiceHandle).getRequestContext().put(sslSocketFactoryProperty,
sslSocketFactory);
}
{code}
So now we're apparently *forced* to figure out how to get runtime access to
wsdls we ship work, because the fallback won't work for SSL.
In the absence of somebody who understands this stuff well enough to advise us,
we have two choices. First choice is to use a different supported transport
than the standard one. I recall reading that CXF's "async" transport used
commons/httpclient, which I know a lot more about and would have a much better
chance of configuring for our needs. The second choice is to find out how
people do SSL with the ?wsdl fallback make this work; there must be a way, no?
> Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
> ------------------------------------------------------------------------------
>
> Key: CONNECTORS-1566
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1566
> Project: ManifoldCF
> Issue Type: Task
> Components: LiveLink connector
> Affects Versions: ManifoldCF 2.12
> Reporter: Karl Wright
> Assignee: Karl Wright
> Priority: Major
> Fix For: ManifoldCF 2.14
>
> Attachments: OTCS_IIS.png, OTCS_Tomcat.png, chrome_cgfC00ujx7.png
>
>
> LAPI is being deprecated. We need to develop a replacement for it using the
> ContentServer Web Services API.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
