[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6
Sascha Zelzer
s.zelzer at dkfz-heidelberg.de
Mon Sep 19 12:35:46 EDT 2011
I can see how it helps to initialize static data for a singleton
consistently for multiple compilation units within one library.
However, I do not understand how the duplication of the "nifty_counter"
symbol in Stream.cpp (if compiled into a static lib) could be prevented
when it is linked from multiple dlls?
- Sascha
On 09/19/2011 06:25 PM, Jean-Christophe Fillion-Robin wrote:
> 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 <mailto: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
>> <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>
>>
>
>
>
>
> --
> +1 919 869 8849
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110919/77e6766a/attachment.html>
More information about the Ctk-developers
mailing list