[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6

Mon Sep 19 15:19:15 UTC 2011

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
> 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> 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">
>> <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>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>wrote:
>>>
>>>> Send Ctk-developers mailing list submissions to
>>>>        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
>>>>
>>>> You can reach the person managing the list at
>>>>        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>
>>>> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched
>>>>        from Non-CTK Host
>>>> To: Sascha Zelzer <s.zelzer at dkfz-heidelberg.de>
>>>> Cc: Anthony Dass <antdass at gmail.com>, ctk-developers at commontk.org
>>>> Message-ID:
>>>>        <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
>>>> > 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
>>>> 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
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110919/9470ea5e/attachment.htm>