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

Mon Sep 19 12:25:07 EDT 2011

ctkSingleton or a similar approach relying on a nifty counter ensures that
only one instance of the singleton will be available within different shared
library. It also ensure that the memory is properly cleaned when the last
library that was referencing the singleton is unloaded.

See
https://secure.wikimedia.org/wikibooks/en/wiki/More_C%2B%2B_Idioms/Nifty_Counter

Jc

On Mon, Sep 19, 2011 at 12:19 PM, Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
> wrote:

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

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