[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6
Sascha Zelzer
s.zelzer at dkfz-heidelberg.de
Mon Sep 19 10:31:01 EDT 2011
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
>> *********************************************
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110919/612a6cef/attachment.html>
More information about the Ctk-developers
mailing list