manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Franke <jornfra...@gmail.com>
Subject Re: CSWS Connector : ServiceConstructionException: Failed to create service
Date Thu, 30 Jan 2020 21:41:15 GMT
find it here:
https://issues.apache.org/jira/browse/CONNECTORS-1635

On Thu, Jan 30, 2020 at 1:48 PM Jörn Franke <jornfranke@gmail.com> wrote:

> Sorry yes i was busy - will do it tonight
>
> Am 30.01.2020 um 13:00 schrieb Karl Wright <daddywri@gmail.com>:
>
> 
> 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 <jornfranke@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 <daddywri@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 <jornfranke@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 <daddywri@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 <jornfranke@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 <daddywri@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 <jornfranke@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 <daddywri@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 <daddywri@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 <jornfranke@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 <jornfranke@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 <daddywri@gmail.com>:
>>>>>>>
>>>>>>> 
>>>>>>> Let me think about that option.
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke <jornfranke@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 <daddywri@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 <jornfranke@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 <daddywri@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 <jornfranke@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 <daddywri@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
<
>>>>>>>>>>> jornfranke@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
<daddywri@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
<daddywri@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 <
>>>>>>>>>>>>> jornfranke@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 <
>>>>>>>>>>>>>> daddywri@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 <
>>>>>>>>>>>>>> jornfranke@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.cizmar@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 <daddywri@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 <
>>>>>>>>>>>>>>> jornfranke@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 <
>>>>>>>>>>>>>>> jornfranke@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 <
>>>>>>>>>>>>>>> daddywri@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 <
>>>>>>>>>>>>>>> jornfranke@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 <
>>>>>>>>>>>>>>> daddywri@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 <
>>>>>>>>>>>>>>> jornfranke@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 <
>>>>>>>>>>>>>>> daddywri@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 <
>>>>>>>>>>>>>>> jornfranke@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

Mime
View raw message