[jira] [Commented] (CONNECTORS-1566) Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
[ https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888581#comment-16888581 ] Karl Wright commented on CONNECTORS-1566: - The TLSClientParameters programmatic way of setting things is still mysterious. I see some examples online here: https://www.programcreek.com/java-api-examples/?api=org.apache.cxf.configuration.jsse.TLSClientParameters This looks promising because TLSClientParameters does have a way of setting a SSLSocketFactory, so if we can get this to be used for the construction of the service, we are over the hump. But somehow we have to get hold of a org.apache.cxf.endpoint.Client object in order to be able to apply TLSClientParameters to it. But it seems like this, too, requires an already-constructed service in order to work: https://www.programcreek.com/java-api-examples/?api=org.apache.cxf.endpoint.Client So this way is blocked too. The only way this could really work in a non-static way is via a "Feature". The service constructors that CXF generates have options for including a list of Feature objects. I do not know what Features are implemented by the JDK's transport but maybe somebody knows? > 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)
[jira] [Commented] (CONNECTORS-1566) Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
[ https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888567#comment-16888567 ] Karl Wright commented on CONNECTORS-1566: - It sounds like the standard solution is to enable non-SSL access to the wsdls alone in the Livelink environment, from what I can read. UGH. > 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)
[jira] [Comment Edited] (CONNECTORS-1566) Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
[
https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (CONNECTORS-1566) Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
[ https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888561#comment-16888561 ] Karl Wright commented on CONNECTORS-1566: - Here's the CXF documentation on the async transport: https://cxf.apache.org/docs/asynchronous-client-http-transport.html One thing here does concern me: enabling this by default is a "Bus-level" property, which means it would affect every other connector that uses CXF too. That's probably a non-starter in the ManifoldCF environment. HOWEVER, the doc here does allude to a different way of setting SSLSocketFactory. I'm going to look into that. > 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)
[jira] [Commented] (CONNECTORS-1566) Develop CSWS connector as a replacement for deprecated LiveLink LAPI connector
[
https://issues.apache.org/jira/browse/CONNECTORS-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888557#comment-16888557
]
Karl Wright commented on CONNECTORS-1566:
-
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
>
