[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6
Sascha Zelzer
s.zelzer at dkfz-heidelberg.de
Mon Sep 19 09:38:48 EDT 2011
Hi Benoit,
Yes, QtSOAP is now always build as a shared library (I only needed to
adapt some CMake code and the export/import defines in qtsoap.h).
- Sascha
On 09/19/2011 03:06 PM, Benoit Bleuze wrote:
> Great work Sascha, those singleton and static lib issues are always a
> pain to debug!
> But how did you fix it? Are you building QtSoap as a dynamic lib? Or
> did you change the QtSoap code?
>
> ------------------------------------------------------------------------
>
> 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/dd4a04d4/attachment.html>
More information about the Ctk-developers
mailing list