[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6
Sascha Zelzer
s.zelzer at dkfz-heidelberg.de
Mon Sep 19 12:19:11 EDT 2011
Hi Jc,
thanks for the pointer, but I would rather not modify the original
QtSOAP code. Besides, ctkSingleton.h wouldn't change the fact that the
singleton would be duplicated if it is defined in a static lib and
linked from multiple shared libs.
Thanks,
Sascha
On 09/19/2011 05:19 PM, Jean-Christophe Fillion-Robin wrote:
> Good catch !
>
> For proper implementation of Singleton, you could refer to ctkSingleton.h
>
> See https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h
>
> Thanks
> Jc
>
> On Mon, Sep 19, 2011 at 10:31 AM, Sascha Zelzer
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
> You're welcome! Thanks to you for your debugging efforts and
> detailed reports here.
>
> -Sascha
>
>
> On 09/19/2011 04:18 PM, Anthony Dass wrote:
>> Hello Sascha,
>>
>> Its really great to know about this fix!. Thank you so much for
>> fixing this so quickly. It would really help us, i'll try with
>> this version.
>>
>> Once again thank you very much!
>>
>> Thanks,
>> ~Anthony
>>
>>
>>
>>
>> On Mon, Sep 19, 2011 at 7:59 AM, Sascha Zelzer
>> <s.zelzer at dkfz-heidelberg.de
>> <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>>
>> Hi Anthony,
>>
>> I finally investigated the issue under Windows (I could not
>> reproduce it on Linux) and just pushed a fix for it to CTK.
>> Please update your CTK sources and build CTK at the
>> superbuild level (this should update the QtSOAP library) to
>> fix the namespace issue.
>>
>> Here is the technical stuff why it went wrong ;-)
>>
>> QtSOAP was build as a static library but it used a singleton
>> called QtSoapNamespace in its code. So using singletons from
>> a static library in multiple DLLs is a bad idea and this is
>> why the namespaces where missing for some QtSoapMessage
>> instances (they where initialized in one DLL, which filled
>> this DLLs QtSOAPNamespace singleton with namespace entries,
>> but serialized to XML in an other DLL, whose singleton did
>> not know anything about the namespaces).
>>
>> Best,
>> Sascha
>>
>>
>>
>>
>> On 09/14/2011 03:24 AM, Anthony Dass wrote:
>>> Hi Sascha and Ben,
>>>
>>> I noticed that only on submitting the SOAP request the
>>> namespaces is getting lost but for the same submission the
>>> response shows the valid message with the namespace included.
>>>
>>> So, in the ctkSoapClient class, I just tried creating the
>>> QtSoapType object (as below) to set as a method arguments
>>> and this works! - gets the required namespace as expected
>>> and the SOAP message is valid one. However if we do the same
>>> construction in ctkDicomHostService and pass to the
>>> ctkSimpleSoapClient object via function call, it doesn't
>>> seem to work. do you have any clue?
>>>
>>> //created in submitSoapRequest of the ctkSimpleSoapClient class
>>> QtSoapType* soapType = new
>>> QtSoapSimpleType(QtSoapQName("state"),
>>> ctkDicomSoapState::toStringValue(ctkDicomAppHosting::IDLE));
>>> request.addMethodArgument(soapType);
>>>
>>>
>>> Below is the SOAP message of the request and response.
>>>
>>> submit Request(request, d->Path); - namespace missing in the
>>> type attribute
>>> =========================
>>> <SOAP-ENV:Envelope
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>>> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>>> xmlns:xsd="htt
>>> p://www.w3.org/1999/XMLSchema
>>> <http://www.w3.org/1999/XMLSchema>">
>>> <SOAP-ENV:Body
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>>> <setState xmlns="http://wg23.dicom.nema.org/">
>>> <state :type="xsd:string">CANCELED</state>
>>> </setState>
>>> </SOAP-ENV:Body>
>>> </SOAP-ENV:Envelope>
>>>
>>> Got Response. Response: - name space for type attribute is
>>> present.
>>> =========================
>>> "<SOAP-ENV:Envelope
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>>> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
>>> xml
>>> ns:xsd="http://www.w3.org/1999/XMLSchema">
>>> <SOAP-ENV:Body
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>>> <SOAP-ENV:setState
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>>> <SOAP-ENV:setStateResponse
>>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>>> xsi:type="xsd:boolean"
>>> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false</SOAP-ENV:setStateResponse>
>>> </SOAP-ENV:setState>
>>> </SOAP-ENV:Body>
>>> </SOAP-ENV:Envelope>
>>>
>>> Thank you!
>>> /Anthony
>>>
>>> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze
>>> <benoit.bleuze at inria.fr <mailto:benoit.bleuze at inria.fr>> wrote:
>>>
>>> We indeed completely depend on QtSoap for creating the
>>> Soap messages. If the soap message looks like this
>>> before any parsong, there is definitely something wrong
>>> in QtSoap.
>>> However it was tha case, I would understand that our
>>> implementation works only on our host, but it also works
>>> with XIP, which is not based on QtSoap.
>>> So either this attribute is simply ignored by the java
>>> implementation, or there is some preprocessing that
>>> strips part of the message?
>>> Definitely worth investigating...
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Hello Sascha and Ben,
>>>
>>> Thank you very much for the quick and detailed answers.
>>>
>>> In addition, when we tried to validate the message
>>> using the online validations -
>>> http://www.xmlvalidation.com we also see the type
>>> attribute :type="xsd:string" is not a valid XML
>>> attribute string and also it looks that the
>>> namespace name is missing here. The string should be
>>> either type="xsd:string" if no namespace is
>>> used(without leading colon), or this
>>> xmlns:type="xsd:string" if xmlns is a namespace name.
>>>
>>> Since the method addMethodAttribute
>>> of QtSoapmessage is setting this, is that we need to
>>> change in the QtSoap module? or any other options?
>>> please advice.
>>>
>>> thank you very much!
>>> /Anthony
>>>
>>>
>>> On Thu, Sep 8, 2011 at 6:47 AM,
>>> <ctk-developers-request at commontk.org
>>> <mailto:ctk-developers-request at commontk.org>> wrote:
>>>
>>> Send Ctk-developers mailing list submissions to
>>> ctk-developers at commontk.org
>>> <mailto:ctk-developers at commontk.org>
>>>
>>> To subscribe or unsubscribe via the World Wide
>>> Web, visit
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> or, via email, send a message with subject or
>>> body 'help' to
>>> ctk-developers-request at commontk.org
>>> <mailto:ctk-developers-request at commontk.org>
>>>
>>> You can reach the person managing the list at
>>> ctk-developers-owner at commontk.org
>>> <mailto:ctk-developers-owner at commontk.org>
>>>
>>> When replying, please edit your Subject line so
>>> it is more specific
>>> than "Re: Contents of Ctk-developers digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: CTK based Hosted App fails when
>>> launched from Non-CTK
>>> Host (Benoit Bleuze)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 8 Sep 2011 12:46:30 +0200 (CEST)
>>> From: Benoit Bleuze <benoit.bleuze at inria.fr
>>> <mailto:benoit.bleuze at inria.fr>>
>>> Subject: Re: [Ctk-developers] CTK based Hosted
>>> App fails when launched
>>> from Non-CTK Host
>>> To: Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
>>> <mailto:s.zelzer at dkfz-heidelberg.de>>
>>> Cc: Anthony Dass <antdass at gmail.com
>>> <mailto:antdass at gmail.com>>,
>>> ctk-developers at commontk.org
>>> <mailto:ctk-developers at commontk.org>
>>> Message-ID:
>>> <610925954.61455.1315478790178.JavaMail.root at zmbs4.inria.fr
>>> <mailto:610925954.61455.1315478790178.JavaMail.root at zmbs4.inria.fr>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi Anthony, Sascha gave you all the technical
>>> answers we had in stock so far, but I can add a
>>> bit of context here, it may help. As Sascha
>>> said, the state/newState switch is due to XIP
>>> not following the specifications. And your
>>> change is valid. We started with "state", but
>>> the only other host we could use being XIP, we
>>> changed it. You are welcome to revert it. I
>>> think we notified Larry (Lawrence Tarbox) of
>>> that problem during the last hackfest in Chapel
>>> Hill. Eventually XIP will change its API there
>>> (or so I hope). Replacing the WSDL files doesn't
>>> change anything since we don't use them to
>>> generate the interface, all the messages are
>>> hard coded soap messages constructed from C++.
>>> Now I know nothing of the WCF unfortunately, so
>>> I can't tell you whether the "type:" keyword is
>>> misinterpreted or whatever. Sascha's suggestion
>>> of changing the casing sounds promising to me. I
>>> remember we used capitals in some actions ,
>>> following the WSDL actually, and had to change
>>> it afterwards for
>>> specifications and XIP compatibility. I
>>> remember Larry telling us the WSDL provided in
>>> the specs was not up to date, and thus we
>>> provide an updated (or at least it was valid
>>> last february) set of WSDL (and siblings) files
>>> there:
>>> http://www.commontk.org/index.php/File:Wsdl_ft.zip
>>> Note that they also have actions starting with
>>> capitals. I have a faint memory of Larry giving
>>> us an explanation as to why they were upper
>>> cased, but I can't remember the reason, my guess
>>> is that the .Net implementation forced them to
>>> do so. And it is very well possible that the XIP
>>> java implementation accepts both casing and the
>>> .NET or WCF are stricter, so I guess you'll have
>>> to choose between the proposed WSDL and the
>>> specifications... Keep us posted of your
>>> progress. Ben ----- Original Message -----
>>> > Hi Anthony,
>>> > Welcome to the ctk-developers list.
>>> > > We've tried adapting one of our DICOM
>>> application into a CTK Based
>>> > > Hosted App. It works well when tried with
>>> the ctkhost - we could
>>> > > launch the app, load the DICOM data and get
>>> through different states
>>> > > as well.
>>> > So far, good news.
>>> > > However when tried launching the same app
>>> with different non-ctk
>>> > > based
>>> > > host, it launches our app but fails to load
>>> any data. This non-ctk
>>> > > based host seems to be written using the WCF
>>> as per specification in
>>> > > DICOM 118.
>>> > Please note that we could only test our
>>> implementation against the XIP
>>> > host (written in Java) so far. So the problems
>>> you are experiencing
>>> > might very well relate to our implementation.
>>> > > On investigating, we noticed that the
>>> initial ?IDLE? message sent by
>>> > > the App upon launch is not getting processed
>>> by the Non-CTK based
>>> > > host.
>>> > > When traced the SOAP communication, we found
>>> out that the messages
>>> > > from the plug-in are getting to the host,
>>> but then they are not
>>> > > processed by WCF because of some WSDL
>>> contacts mismatch. Thus the
>>> > > host
>>> > > does not receive any messages. Here?s the
>>> log message:
>>> > > < Message > The message with Action ''
>>> cannot be processed at the
>>> > > receiver, due to a ContractFilter mismatch
>>> at the
>>> > > EndpointDispatcher.
>>> > > This may be because of either a contract
>>> mismatch (mismatched
>>> > > Actions
>>> > > between sender and receiver) or a
>>> binding/security mismatch between
>>> > > the sender and the receiver. Check that
>>> sender and receiver have the
>>> > > same contract and the same binding
>>> (including security requirements,
>>> > > e.g. Message, Transport, None). </ Message >
>>> > > When debugging the WCF processing of the
>>> message we get the
>>> > > deserialization error:
>>> > > "The ':' character, hexadecimal value 0x3A,
>>> cannot be included in a
>>> > > name. Line 4, position 11."
>>> > > Here?s the SOAP message braced between the
>>> CTK-plugin and Non-CTK
>>> > > based Host:
>>> > > < SOAP-ENV:Envelope xmlns:SOAP-ENV = "
>>> > > http://schemas.xmlsoap.org/soap/envelope/ "
>>> SOAP-ENV:encodingStyle =
>>> > > "
>>> > > http://schemas.xmlsoap.org/soap/encoding/ "
>>> xmlns:xsd = "
>>> > > http://www.w3.org/1999/XMLSchema " >
>>> > > < SOAP-ENV:Body xmlns:SOAP-ENV = "
>>> > > http://schemas.xmlsoap.org/soap/envelope/ " >
>>> > > < notifyStateChanged xmlns = "
>>> http://wg23.dicom.nema.org/ " >
>>> > > < newState :type = " xsd:string " > IDLE </
>>> newState >
>>> > > </ notifyStateChanged >
>>> > > </ SOAP-ENV:Body >
>>> > > </ SOAP-ENV:Envelope >
>>> > > We can see the ?:type? item in the newState
>>> element that?s causing
>>> > > the
>>> > > error in WCF. Also, per DICOM supplement 118
>>> it should be called
>>> > > ?state?, not ?newState?.
>>> > Looking at the debug output from the CTK
>>> hosted app, the xml namespace
>>> > for the "type" attribute in the "newState" tag
>>> is intact. So I am
>>> > wondering it the output above has already been
>>> modified somehow by the
>>> > WCF host or if it is the original message from
>>> the CTK hosted app.
>>> > > Here?s the example of the SOAP message
>>> generated by Non-CTK based
>>> > > HostedApp: < s:Envelope xmlns:s = "
>>> > > http://schemas.xmlsoap.org/soap/envelope/ "
>>> > < s:Body > <
>>> > > NotifyStateChanged xmlns = "
>>> > >
>>> http://dicom.nema.org/PS3.19/HostService-20100825 "
>>> > < state > IDLE
>>> > > </ state > </ NotifyStateChanged > </ s:Body
>>> > </ s:Envelope >
>>> > > Next, we tried changing ?newState? to
>>> ?state? but again it fails
>>> > > when
>>> > > tried with the non-ctk based host and
>>> producing the same error.
>>> > I think it is still either related to the
>>> ":type" attribute or the
>>> > error described below. Concerning
>>> state/newState, please also see my
>>> > comments below.
>>> > > ...
>>> > > 2011-09-06 17:17:59,609 <faultstring
>>> xsi:type="xsd:string"
>>> > > xmlns:xsi="
>>> > > http://www.w3.org/1999/XMLSchema-instance
>>> ">The message with Action
>>> > > ''
>>> > > cannot be processed at the receiver, due to
>>> a ContractFilter
>>> > > mismatch
>>> > > at the EndpointDispatcher. This may be
>>> because of either a contract
>>> > > mismatch (mismatched Actions between sender
>>> and receiver) or a
>>> > > binding/security mismatch between the sender
>>> and the receiver. Check
>>> > > that sender and receiver have the same
>>> contract and the same binding
>>> > > (including security requirements, e.g.
>>> Message, Transport,
>>> > > None).</faultstring> ...
>>> > This actually hints at a problem concerning
>>> the action names. Looking
>>> > at the WSDL, the operation names start with
>>> upper case latters, where
>>> > we are using lower case (unfortunately, the
>>> text in the DICOM Part 19
>>> > specs refer to the method names with starting
>>> lower case letters).
>>> > > I even tried replacing the WSDL files with
>>> the one provided by
>>> > > Non-CTK
>>> > > based host, but still it doesn?t seem to work.
>>> > Yes, that does not change the actual behavior.
>>> > > When looked at the code, I noticed a comment
>>> in the CTK code (below
>>> > > methods) ?spec would be "state", java has
>>> "newState" FIX
>>> > > JAVA/STANDARD?. Could this be something we
>>> need to look for? If so
>>> > > may
>>> > > I know what would be the change in Java side.
>>> > Unfortunately, again, the text in the specs
>>> refer to "newState" for
>>> > the argument name and this is what the XIP
>>> host is using. So we used
>>> > it too for testing with XIP. But I agree that
>>> the WSDL should be the
>>> > definite guide and we should use "state" when
>>> not testing with XIP.
>>> > My advice would be to keep your modification
>>> ("newState" -> "state")
>>> > and also try to modify the action (method)
>>> names in
>>> > ctkDicomAppService.cpp (lines 40 - 60) to use
>>> upper case for the first
>>> > letter.
>>> > I would be happy if you could keep us posted
>>> about your progress.
>>> > Thanks,
>>> > Sascha
>>> > _______________________________________________
>>> > Ctk-developers mailing list
>>> > Ctk-developers at commontk.org
>>> <mailto:Ctk-developers at commontk.org>
>>> >
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://public.kitware.com/pipermail/ctk-developers/attachments/20110908/e75bdbbd/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> <mailto:Ctk-developers at commontk.org>
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>
>>>
>>> End of Ctk-developers Digest, Vol 26, Issue 6
>>> *********************************************
>>>
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>
>
> --
> +1 919 869 8849 <tel:%2B1%20919%20869%208849>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110919/bdc37531/attachment.html>
More information about the Ctk-developers
mailing list