Hi, I've been waiting for a ticket to appear that summarizes what's been happening for this issue but I haven't seen one. Can you bring us up to date? Thanks in advance, Karl
On Wed, Jan 22, 2020 at 12:06 PM Jörn Franke <jornfra...@gmail.com> wrote: > i try to help. I will create a Jira if you do not mind where I also > explain how I make the WSDL thing working for https, which could not have > worked before. > Reason is that for fetching the WSDL it uses a completely different > approach (WSDL4Java), where in the connector code no truststore was defined > (only for doing actually SOAP requests). This was fixed and it can create > the service. But then after service creation in the following lines of > codes it fetches the xsd which does not work (it says it cannot find them), > which is strange as the Url is correct and reachable. Hence, I suspect it > does not understand it is a http URL but instead it tries to open it on the > file system. > I am pretty busy at the moment, but I try to support and give feedback as > soon as possible. > > I don’t know what is different to your 2 installations - maybe they are > http or partly http or there is some patch to the code that did not make it > into the git. > I can tell that I can test with Content Server 10 as well as 16. > SOAP UI has no problem and in the end it does exactly the same (starting > from the https WSDL etc.) > > Am 22.01.2020 um 13:17 schrieb Karl Wright <daddy...@gmail.com>: > > > The whole web services java + cxf architecture is pretty mysterious. The > only way I've made progress is by finding code snippets in stackoverflow; > the documentation is not adequate. BUT there are configuration files that > determine how the WSDL parser resolves references. I don't know how we > would force that configuration to be in effect but something like that > would need to be done. I'm just surprised that you're having this problem > when two other installations didn't. There must be a difference somewhere. > > Karl > > > On Wed, Jan 22, 2020 at 5:11 AM Jörn Franke <jornfra...@gmail.com> wrote: > >> Sorry I did not have much time, my next action plan is to try to modify >> the catalogue xml to fetch it directly from the https. For some reasons it >> can fetch the WSDL (after my fix), but not the included xsds despite that >> in the error message it has the correct url of them. >> Are you aware of any configuration that tries to force file based access >> of those? In the Code i did not find anything suspicious. >> >> Am 22.01.2020 um 10:28 schrieb Karl Wright <daddy...@gmail.com>: >> >> >> Has there been any news? >> I'd love to get this tied up so that you're able to proceed. >> Karl >> >> On Thu, Jan 16, 2020 at 12:08 PM Jörn Franke <jornfra...@gmail.com> >> wrote: >> >>> Ok I understand. I will try and let you know. Thanks again very much for >>> your fast and detailed answer. Really appreciated. I hope I can give back >>> with the solution to fetch WSDLs from https and maybe a solution to this >>> problem (maybe other will face this as well). >>> >>> About the connector: the WSDL is successfully fetched via https (not >>> file - no clue why) - after the modification I made. The only problem I see >>> now is that the xsd to which the WSDL is referring are not fetched. The >>> bizarre thing is that the https url that it mention for the xsd is >>> absolutely correct. So I assume it does not understand an http url, maybe >>> that is related to configuration. >>> >>> Am 16.01.2020 um 14:53 schrieb Karl Wright <daddy...@gmail.com>: >>> >>> >>> The WSDLS are bundled with the jar. We intended this to be the ONLY way >>> the wsdls were accessed, and made lots of changes to the wsdls accordingly, >>> so that they referenced other wsdls via the "file system". The wsdls are >>> the fixed up ones that are used to build the java stubs locally, plus a >>> config file that's supposed to tell CXF how to resolve referenced wsdls. >>> That config file may or may not be correct, because we never were able to >>> get CXF to use the local resource wsdls during actual connection. >>> >>> Except now they seem to be both fetched via https AND locally sourced. >>> I have no idea how that can be. I had assumed it was done one way or the >>> other but not both. >>> >>> Perhaps the problem is that the configuration file is being read but the >>> resource wsdls are not being found? Removing the meta-inf from the jar >>> would then force everything to go through https. Ideally I'd love it if >>> that wasn't needed and we could get the resource fetch working everywhere. >>> >>> >>> Karl >>> >>> >>> On Thu, Jan 16, 2020 at 8:20 AM Jörn Franke <jornfra...@gmail.com> >>> wrote: >>> >>>> Well i am not sure how they solved it - I will share a tested solution >>>> in Jira and everyone can check. Maybe their wsdl is accessible through >>>> http? >>>> >>>> What works is doing call through https, but thee fetching of WSDL did >>>> not - as this is through another mechanism. >>>> >>>> I don’t think that the open text is different, the WSDL look very >>>> similar to the repository. >>>> >>>> The strange thing is that for this error message it tries to access the >>>> xsd through a https url (which is perfectly accessible for the server). >>>> Could it be that the connector restrict itself somehow to local file >>>> system only or similar? >>>> Have you faced this issue before? >>>> >>>> >>>> >>>> Am 16.01.2020 um 12:56 schrieb Karl Wright <daddy...@gmail.com>: >>>> >>>> >>>> I should say that we have (AFAICT) at least two independent >>>> installations of the csws connector working in the field, at least one of >>>> them using secure connections. >>>> >>>> Karl >>>> >>>> >>>> On Thu, Jan 16, 2020 at 6:54 AM Karl Wright <daddy...@gmail.com> wrote: >>>> >>>>> We solved the WSDL fetching through HTTPS, or thought we had, by >>>>> restructuring the code according to a number of articles we found. This >>>>> was supposedly tested and worked in one installation. Nobody has ever >>>>> reported issues with the wsdls being fetched however; I worry that you may >>>>> have a different version of OpenText that is incompatible with the one we >>>>> developed against. That's the problem with this kind of architecture; >>>>> unless the wsdls are included in the jar there can be issues. We tried to >>>>> do that too but were unable to get it to work. >>>>> >>>>> Karl >>>>> >>>>> >>>>> On Thu, Jan 16, 2020 at 5:34 AM Jörn Franke <jornfra...@gmail.com> >>>>> wrote: >>>>> >>>>>> Ok i fixed the source to fetch WSDL from https (it is not perfect yet >>>>>> as it does not use the truststore yet but this I can fix) - I will share >>>>>> later in a Jira. >>>>>> It is however now unable to locate the imported document >>>>>> /Authentication?xsd=2 relative to Authenticaton?wsdl#types1 >>>>>> >>>>>> I will look into this, but if someone has come cross it then please >>>>>> let me know. >>>>>> >>>>>> Am 16.01.2020 um 10:22 schrieb Jörn Franke <jornfra...@gmail.com>: >>>>>> >>>>>> >>>>>> Coming back to the original topic. I believe SSL was never fully >>>>>> solved from what i read in the corresponding issue. Apparently, the >>>>>> fetching of the WSDL itself through https was not possible. Do you >>>>>> remember >>>>>> still some insights beyond what is written in the issue ? >>>>>> >>>>>> Am 16.01.2020 um 00:37 schrieb Karl Wright <daddy...@gmail.com>: >>>>>> >>>>>> >>>>>> Let me think about that option. >>>>>> >>>>>> Karl >>>>>> >>>>>> >>>>>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke <jornfra...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> We could make it configurable, e.g. in properties.xml. Here people >>>>>>> could set it to SSL, TLS, TLSv1.2 (to restrict it to TLS1.2 => some >>>>>>> companies may want that!). Is this a viable option? That would be also >>>>>>> future proof. We can leave it by default to SSL, but we should put in >>>>>>> the >>>>>>> example config files TLS by default (so new starters do not get even the >>>>>>> idea to use an outdated protocol) AND put a comment with recommendation >>>>>>> to >>>>>>> use/enforce always newest protocols for security reasons. Of course, the >>>>>>> choice is then with the people using the software. >>>>>>> Could that be something sensible from your point of view? >>>>>>> >>>>>>> On Wed, Jan 15, 2020 at 11:14 PM Karl Wright <daddy...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> It's rather immaterial what browsers do here. What's important is >>>>>>>> what *existing servers* support, since that is what we're connecting >>>>>>>> with. >>>>>>>> >>>>>>>> I tend to agree that *most* people have probably upgraded to web >>>>>>>> servers that support TLS. But we can't guarantee it, nor can we assume >>>>>>>> that people have upgraded to the most modern version of TLS >>>>>>>> exclusively. >>>>>>>> In fact I think we can assume they have *not*. When the SSL issues >>>>>>>> were >>>>>>>> discovered a couple of years back, the standard recommendation was >>>>>>>> simply >>>>>>>> to *disable* SSLv1 and SSLv2, not to upgrade to Java 11 or some such. >>>>>>>> We >>>>>>>> still support (and have people using!!) early forms of NTLM (v1 to be >>>>>>>> specific), for instance. We're not going to be able to wag the dog >>>>>>>> here. >>>>>>>> Breaking changes of this kind usually mean we go to a whole new major >>>>>>>> version of MCF. >>>>>>>> >>>>>>>> However, if you can show that SSLContext.getSSLFactory("TLS") >>>>>>>> produces a SSLSocketFactory that works with all versions of TLS and SSL >>>>>>>> that do not have known security holes, I would support changing over to >>>>>>>> that. If it turns out we need much more specificity about the kind of >>>>>>>> SSLSocketFactory we produce, then we need a better solution anyhow for >>>>>>>> handling multiple protocols in one socket factory. >>>>>>>> >>>>>>>> Karl >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 15, 2020 at 5:17 AM Jörn Franke <jornfra...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Karl, >>>>>>>>> >>>>>>>>> No it does not. I can look into that further, but Current browsers >>>>>>>>> stop supporting anything below TLSv1.2 in March 2020. >>>>>>>>> Then TLS exists since more than ten years. I expect any server >>>>>>>>> running nowadays will always have tls support. >>>>>>>>> SSL itself is not supported since some time now. From a security >>>>>>>>> perspective it should even break servers that run only SSL as they are >>>>>>>>> inherently insecure and also clients that only support SSL are adding >>>>>>>>> to >>>>>>>>> this. >>>>>>>>> However if you have an idea how this should be made configurable >>>>>>>>> then I can look into this. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Am 15.01.2020 um 10:52 schrieb Karl Wright <daddy...@gmail.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Mcf currently requires jdk8. Jdk11 is non trivial to support >>>>>>>>> because of the removal of many jdk classes connectors need. It will >>>>>>>>> be >>>>>>>>> ported at some point but not lightly. >>>>>>>>> >>>>>>>>> Similarly, disabling SSL would certainly break many installations >>>>>>>>> upon upgrade and we do not do that lightly. >>>>>>>>> >>>>>>>>> The core methods that mcf supplies its connectors should therefore >>>>>>>>> be updated to support but not mandate tls. The protocol >>>>>>>>> specification one >>>>>>>>> gives to sslcontext is not a detailed one but rather a major version. >>>>>>>>> What >>>>>>>>> I don't know is whether"tlsv1" also allows for older protocols etc. >>>>>>>>> >>>>>>>>> Karl >>>>>>>>> >>>>>>>>> On Wed, Jan 15, 2020, 1:19 AM Jörn Franke <jornfra...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Yes I am doing that but I will need to rebuild. >>>>>>>>>> I don’t recommend TLSv1 - this is already outphased and will lock >>>>>>>>>> out TLSv1.2. I try TLS only as it includes all TLS protocols >>>>>>>>>> (depends on >>>>>>>>>> JDK). >>>>>>>>>> >>>>>>>>>> SSL will not be supported by this (however as I said there are >>>>>>>>>> other parts of the code where there is a getInstance(TLS). And some >>>>>>>>>> caveats: On JDK6+7 TLS only means TLSv1 (and newer TLS Protocols are >>>>>>>>>> deactivated) on JDK8 it means also that newer TLS protocols are >>>>>>>>>> enabled. >>>>>>>>>> To be honest in my opinion - a SSL only one is a significant >>>>>>>>>> security hole and given how old TLS support is JDK i would be >>>>>>>>>> surprised if >>>>>>>>>> there is someone using such a server (most Organisations should >>>>>>>>>> switch to >>>>>>>>>> TLSv1.2 in any case as all protocols below have been broken). >>>>>>>>>> While it works for all JDKs - probably JDK8 should be recommended >>>>>>>>>> as it seems to have all TLS protocols activated when using „TLS“. >>>>>>>>>> Older >>>>>>>>>> JDKs seem to deactivate TLSv1.1 and TLSv1.2 when using TLS. I will >>>>>>>>>> write >>>>>>>>>> more about this in the JIRA, once I verified that this solves the >>>>>>>>>> problem. >>>>>>>>>> Then TLSv1.3 is JDK11 only - I will investigate what that implies. >>>>>>>>>> Does ManifoldCf supports JDK11? >>>>>>>>>> >>>>>>>>>> Am 15.01.2020 um 00:08 schrieb Karl Wright <daddy...@gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think you can just change the code to read as follows when it >>>>>>>>>> creates the SSLContext: >>>>>>>>>> >>>>>>>>>> SSLContext ctx = SSLContext.getInstance("TLSv1"); >>>>>>>>>> I don't know if TLS will downgrade to SSL if that's all that's >>>>>>>>>> available. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Karl >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 14, 2020 at 6:02 PM Jörn Franke <jornfra...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Yes it you do not change this setting as what I suspect happens >>>>>>>>>>> here. See my previous mail for details. >>>>>>>>>>> >>>>>>>>>>> Am 14.01.2020 um 23:51 schrieb Karl Wright <daddy...@gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It looks looks TLS is actually enabled in the SSLSocketFactory >>>>>>>>>>> framework based on how you create the SSLSocketContext. See: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://docs.oracle.com/cd/E19698-01/816-7609/security-83/index.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Karl >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 14, 2020 at 5:48 PM Karl Wright <daddy...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> The design of ManifoldCF deliberately manages keystores on a >>>>>>>>>>>> connection by connection basis, not globally. If you think the >>>>>>>>>>>> only way to >>>>>>>>>>>> implement TLS is via global keystore I very much doubt it. >>>>>>>>>>>> >>>>>>>>>>>> I am on the road until late tomorrow but somewhere along the >>>>>>>>>>>> line I can do some research into why TLS won't work as we are >>>>>>>>>>>> currently >>>>>>>>>>>> doing it. >>>>>>>>>>>> >>>>>>>>>>>> Karl >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 14, 2020 at 12:56 PM Jörn Franke < >>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> These are TLS only. So maybe you have other servers where tls >>>>>>>>>>>>> and ssl are possible and it downgrades to ssl.however, this is >>>>>>>>>>>>> speculation >>>>>>>>>>>>> and I need to verify it. I have to rebuilt manifold for that. >>>>>>>>>>>>> Probably I >>>>>>>>>>>>> have to reinstall everything as the keystorefactory is a >>>>>>>>>>>>> dependency in the >>>>>>>>>>>>> connector. >>>>>>>>>>>>> >>>>>>>>>>>>> Am 14.01.2020 um 18:34 schrieb Karl Wright <daddy...@gmail.com >>>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If you can recommend changes to support TLS, that would be >>>>>>>>>>>>> great. The basic infrastructure should still work; it is just a >>>>>>>>>>>>> custom >>>>>>>>>>>>> keystone and associated SSLSocketFactory, which I think also is >>>>>>>>>>>>> used for >>>>>>>>>>>>> TLS connections, unless I am missing something. >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jan 14, 2020, 9:38 AM Jörn Franke < >>>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Yes this works fine. I believe the error comes from the fact >>>>>>>>>>>>>> that TLS connections are not supported. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 14.01.2020 um 15:31 schrieb Michael Cizmar < >>>>>>>>>>>>>> michael.ciz...@mcplusa.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you want to test the url and the ssl, I would recommend >>>>>>>>>>>>>> attempting using SSLPoke to confirm that they keystore is setup >>>>>>>>>>>>>> properly: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/MichalHecko/SSLPoke >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *From: *Karl Wright <daddy...@gmail.com> >>>>>>>>>>>>>> *Reply-To: *"user@manifoldcf.apache.org" < >>>>>>>>>>>>>> user@manifoldcf.apache.org> >>>>>>>>>>>>>> *Date: *Tuesday, January 14, 2020 at 7:21 AM >>>>>>>>>>>>>> *To: *"user@manifoldcf.apache.org" < >>>>>>>>>>>>>> user@manifoldcf.apache.org> >>>>>>>>>>>>>> *Subject: *Re: CSWS Connector : >>>>>>>>>>>>>> ServiceConstructionException: Failed to create service >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hmm, others have succeeded setting up SSL connections with >>>>>>>>>>>>>> the current code. Hoping they chime in here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Karl >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jan 14, 2020, 8:19 AM Jörn Franke < >>>>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems that it has indeed a certificate issue as it cannot >>>>>>>>>>>>>> find a valid certification path to the target. The thing is: I >>>>>>>>>>>>>> added those >>>>>>>>>>>>>> certificates in the UI should it should not happen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 10.01.2020 um 20:51 schrieb Jörn Franke < >>>>>>>>>>>>>> jornfra...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2.15 ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will try on the weekend to see if I can get some logs out >>>>>>>>>>>>>> of it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 10.01.2020 um 19:02 schrieb Karl Wright < >>>>>>>>>>>>>> daddy...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can I ask what version of MCF you are using? There were >>>>>>>>>>>>>> issues with SSL in the first release of the csws connector if I >>>>>>>>>>>>>> recall >>>>>>>>>>>>>> correctly, that were fixed for the second release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Karl >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 11:42 AM Jörn Franke < >>>>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added root, intermediate and server certificate (in base64 >>>>>>>>>>>>>> cer, it seems to be recognized by manifoldcf), but I still get >>>>>>>>>>>>>> the same >>>>>>>>>>>>>> message. I will try to get somehow the full stacktrace >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 10.01.2020 um 17:21 schrieb Karl Wright < >>>>>>>>>>>>>> daddy...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you are using SSL you need to have the proper certificate >>>>>>>>>>>>>> saved in the connection's keystore. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Karl >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 11:20 AM Jörn Franke < >>>>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is actually a server using configuration of the command - >>>>>>>>>>>>>> driven multi-process model (but the agents executed as a service >>>>>>>>>>>>>> and the >>>>>>>>>>>>>> war on a tomcat executed as a service) under Linux. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I thought as well that it cannot reach the webservices, the >>>>>>>>>>>>>> question is why. On the same server I can reach the webservices >>>>>>>>>>>>>> and fetch >>>>>>>>>>>>>> the WSDL without issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe sth related to ssl ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 10.01.2020 um 14:59 schrieb Karl Wright < >>>>>>>>>>>>>> daddy...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> How are you running manifoldcf? Single process example, or a >>>>>>>>>>>>>> custom setup of some kind? >>>>>>>>>>>>>> >>>>>>>>>>>>>> This exception is a "catch all" exception generated far below >>>>>>>>>>>>>> anything in ManifoldCF, but usually means it cannot download the >>>>>>>>>>>>>> WSDLs from >>>>>>>>>>>>>> the service. Getting the full exception dumped in the log >>>>>>>>>>>>>> requires a >>>>>>>>>>>>>> "hack" to the check() method of the connector, but I'm pretty >>>>>>>>>>>>>> sure that's >>>>>>>>>>>>>> what's happening anyway. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Karl >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 8:50 AM Jörn Franke < >>>>>>>>>>>>>> jornfra...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to use the CSWS connector, but already for the >>>>>>>>>>>>>> Authority connection I receive a >>>>>>>>>>>>>> org.apache.cxf.service.factory.ServiceConstructionException: >>>>>>>>>>>>>> Failed to >>>>>>>>>>>>>> create service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unfortunately I don’t see more details , also not in the log >>>>>>>>>>>>>> (debug is activated). I try to get a little bit more output by >>>>>>>>>>>>>> modifying >>>>>>>>>>>>>> the connector, but maybe someone has already an idea why this >>>>>>>>>>>>>> can happen? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Are there some special instructions to use it? The pointers >>>>>>>>>>>>>> to the webservices are correct, I tested via Curl and SOAPUI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you. >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> >>>>>>>>>>>>>>