[ 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)