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

Mon Sep 19 09:06:08 EDT 2011

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? ----- Original Message -----
> 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
> > > > > *********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110919/a496d8a1/attachment.html>