<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Benoit,<br>
<br>
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).<br>
<br>
- Sascha<br>
<br>
On 09/19/2011 03:06 PM, Benoit Bleuze wrote:
<blockquote
cite="mid:1116230078.216317.1316437568240.JavaMail.root@zmbs4.inria.fr"
type="cite">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: Times New Roman; font-size: 12pt; color:
#000000">Great work Sascha, those singleton and static lib
issues are always a pain to debug!
<div>But how did you fix it? Are you building QtSoap as a
dynamic lib? Or did you change the QtSoap code?<br>
<br>
<hr id="zwchr">
<blockquote style="border-left:2px solid rgb(16, 16,
255);margin-left:5px;padding-left:5px;"> Hi Anthony,<br>
<br>
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.<br>
<br>
Here is the technical stuff why it went wrong ;-)<br>
<br>
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).<br>
<br>
Best,<br>
Sascha<br>
<br>
<br>
<br>
On 09/14/2011 03:24 AM, Anthony Dass wrote:
<blockquote
cite="mid:CA+rdb6Qv6VzB+2Q6nFQmxmnAxRQuSrLVDm07M-JvEms89G9cwg@mail.gmail.com">Hi
Sascha and Ben,<br>
<br>
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.<br>
<br>
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? <br>
<br>
//created in submitSoapRequest of the ctkSimpleSoapClient
class<br>
QtSoapType* soapType = new
QtSoapSimpleType(QtSoapQName("state"),
ctkDicomSoapState::toStringValue(ctkDicomAppHosting::IDLE));<br>
request.addMethodArgument(soapType);<br>
<br>
<br>
Below is the SOAP message of the request and response.<br>
<br>
submit Request(request, d->Path); - namespace missing
in the type attribute<br>
=========================<br>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
SOAP-ENV:encodingStyle="<a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/encoding/"
target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>"
xmlns:xsd="htt<br>
p://<a moz-do-not-send="true"
href="http://www.w3.org/1999/XMLSchema" target="_blank">www.w3.org/1999/XMLSchema</a>"><br>
<SOAP-ENV:Body xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<setState xmlns="<a moz-do-not-send="true"
href="http://wg23.dicom.nema.org/" target="_blank">http://wg23.dicom.nema.org/</a>"><br>
<state :type="xsd:string">CANCELED</state><br>
</setState><br>
</SOAP-ENV:Body><br>
</SOAP-ENV:Envelope><br>
<br>
Got Response. Response: - name space for type attribute
is present.<br>
=========================<br>
"<SOAP-ENV:Envelope xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
SOAP-ENV:encodingStyle="<a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/encoding/"
target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>"
xml<br>
ns:xsd="<a moz-do-not-send="true"
href="http://www.w3.org/1999/XMLSchema" target="_blank">http://www.w3.org/1999/XMLSchema</a>"><br>
<SOAP-ENV:Body xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<SOAP-ENV:setState xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<SOAP-ENV:setStateResponse xmlns:SOAP-ENV="<a
moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
xsi:type="xsd:boolean" xmlns:xsi="<a
moz-do-not-send="true"
href="http://www.w3.org/1999/XMLSchema-instance"
target="_blank">http://www.w3.org/1999/XMLSchema-instance</a>">false</SOAP-ENV:setStateResponse><br>
</SOAP-ENV:setState><br>
</SOAP-ENV:Body><br>
</SOAP-ENV:Envelope><br>
<br>
Thank you!<br>
/Anthony<br>
<br>
<div class="gmail_quote">On Fri, Sep 9, 2011 at 4:31 AM,
Benoit Bleuze <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:benoit.bleuze@inria.fr" target="_blank">benoit.bleuze@inria.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>
<div style="font-family: Times New Roman; font-size:
12pt; color: rgb(0, 0, 0);">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.
<div> 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. </div>
<div>So either this attribute is simply ignored by
the java implementation, or there is some
preprocessing that strips part of the message?</div>
<div>Definitely worth investigating...<br>
<br>
<hr>
<div>
<div class="h5">
<blockquote style="border-left: 2px solid
rgb(16, 16, 255); margin-left: 5px;
padding-left: 5px;">
<div class="gmail_quote">Hello Sascha and
Ben,</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Thank you very
much for the quick and detailed
answers. </div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote"> In addition,
when we tried to validate the message
using the online validations - <a
moz-do-not-send="true"
href="http://www.xmlvalidation.com"
target="_blank">http://www.xmlvalidation.com</a> 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.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote"> <br>
</div>
<div class="gmail_quote">thank you very
much!</div>
<div class="gmail_quote">/Anthony</div>
<div class="gmail_quote"><br>
</div>
<br>
<div class="gmail_quote">On Thu, Sep 8,
2011 at 6:47 AM, <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ctk-developers-request@commontk.org"
target="_blank">ctk-developers-request@commontk.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">Send
Ctk-developers mailing list
submissions to<br>
<a moz-do-not-send="true"
href="mailto:ctk-developers@commontk.org"
target="_blank">ctk-developers@commontk.org</a><br>
<br>
To subscribe or unsubscribe via the
World Wide Web, visit<br>
<a moz-do-not-send="true"
href="http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers"
target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers</a><br>
or, via email, send a message with
subject or body 'help' to<br>
<a moz-do-not-send="true"
href="mailto:ctk-developers-request@commontk.org"
target="_blank">ctk-developers-request@commontk.org</a><br>
<br>
You can reach the person managing the
list at<br>
<a moz-do-not-send="true"
href="mailto:ctk-developers-owner@commontk.org"
target="_blank">ctk-developers-owner@commontk.org</a><br>
<br>
When replying, please edit your
Subject line so it is more specific<br>
than "Re: Contents of Ctk-developers
digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: CTK based Hosted App fails
when launched from Non-CTK<br>
Host (Benoit Bleuze)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 8 Sep 2011 12:46:30 +0200
(CEST)<br>
From: Benoit Bleuze <<a
moz-do-not-send="true"
href="mailto:benoit.bleuze@inria.fr"
target="_blank">benoit.bleuze@inria.fr</a>><br>
Subject: Re: [Ctk-developers] CTK
based Hosted App fails when launched<br>
from Non-CTK Host<br>
To: Sascha Zelzer <<a
moz-do-not-send="true"
href="mailto:s.zelzer@dkfz-heidelberg.de"
target="_blank">s.zelzer@dkfz-heidelberg.de</a>><br>
Cc: Anthony Dass <<a
moz-do-not-send="true"
href="mailto:antdass@gmail.com"
target="_blank">antdass@gmail.com</a>>,
<a moz-do-not-send="true"
href="mailto:ctk-developers@commontk.org"
target="_blank">ctk-developers@commontk.org</a><br>
Message-ID:<br>
<<a moz-do-not-send="true"
href="mailto:610925954.61455.1315478790178.JavaMail.root@zmbs4.inria.fr"
target="_blank">610925954.61455.1315478790178.JavaMail.root@zmbs4.inria.fr</a>><br>
Content-Type: text/plain;
charset="utf-8"<br>
<br>
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<br>
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: <a
moz-do-not-send="true"
href="http://www.commontk.org/index.php/File:Wsdl_ft.zip"
target="_blank">http://www.commontk.org/index.php/File:Wsdl_ft.zip</a>
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 -----<br>
> Hi Anthony,<br>
> Welcome to the ctk-developers
list.<br>
> > We've tried adapting one of
our DICOM application into a CTK Based<br>
> > Hosted App. It works well
when tried with the ctkhost - we could<br>
> > launch the app, load the
DICOM data and get through different
states<br>
> > as well.<br>
> So far, good news.<br>
> > However when tried launching
the same app with different non-ctk<br>
> > based<br>
> > host, it launches our app
but fails to load any data. This
non-ctk<br>
> > based host seems to be
written using the WCF as per
specification in<br>
> > DICOM 118.<br>
> Please note that we could only
test our implementation against the
XIP<br>
> host (written in Java) so far. So
the problems you are experiencing<br>
> might very well relate to our
implementation.<br>
> > On investigating, we noticed
that the initial ?IDLE? message sent
by<br>
> > the App upon launch is not
getting processed by the Non-CTK based<br>
> > host.<br>
> > When traced the SOAP
communication, we found out that the
messages<br>
> > from the plug-in are getting
to the host, but then they are not<br>
> > processed by WCF because of
some WSDL contacts mismatch. Thus the<br>
> > host<br>
> > does not receive any
messages. Here?s the log message:<br>
> > < Message > The
message with Action '' cannot be
processed at the<br>
> > receiver, due to a
ContractFilter mismatch at the<br>
> > EndpointDispatcher.<br>
> > This may be because of
either a contract mismatch (mismatched<br>
> > Actions<br>
> > between sender and receiver)
or a binding/security mismatch between<br>
> > the sender and the receiver.
Check that sender and receiver have
the<br>
> > same contract and the same
binding (including security
requirements,<br>
> > e.g. Message, Transport,
None). </ Message ><br>
> > When debugging the WCF
processing of the message we get the<br>
> > deserialization error:<br>
> > "The ':' character,
hexadecimal value 0x3A, cannot be
included in a<br>
> > name. Line 4, position 11."<br>
> > Here?s the SOAP message
braced between the CTK-plugin and
Non-CTK<br>
> > based Host:<br>
> > < SOAP-ENV:Envelope
xmlns:SOAP-ENV = "<br>
> > <a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
" SOAP-ENV:encodingStyle =<br>
> > "<br>
> > <a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/encoding/"
target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>
" xmlns:xsd = "<br>
> > <a moz-do-not-send="true"
href="http://www.w3.org/1999/XMLSchema"
target="_blank">http://www.w3.org/1999/XMLSchema</a>
" ><br>
> > < SOAP-ENV:Body
xmlns:SOAP-ENV = "<br>
> > <a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
" ><br>
> > < notifyStateChanged
xmlns = " <a moz-do-not-send="true"
href="http://wg23.dicom.nema.org/"
target="_blank">http://wg23.dicom.nema.org/</a>
" ><br>
> > < newState :type = "
xsd:string " > IDLE </ newState
><br>
> > </ notifyStateChanged
><br>
> > </ SOAP-ENV:Body ><br>
> > </ SOAP-ENV:Envelope ><br>
> > We can see the ?:type? item
in the newState element that?s causing<br>
> > the<br>
> > error in WCF. Also, per
DICOM supplement 118 it should be
called<br>
> > ?state?, not ?newState?.<br>
> Looking at the debug output from
the CTK hosted app, the xml namespace<br>
> for the "type" attribute in the
"newState" tag is intact. So I am<br>
> wondering it the output above has
already been modified somehow by the<br>
> WCF host or if it is the original
message from the CTK hosted app.<br>
> > Here?s the example of the
SOAP message generated by Non-CTK
based<br>
> > HostedApp: < s:Envelope
xmlns:s = "<br>
> > <a moz-do-not-send="true"
href="http://schemas.xmlsoap.org/soap/envelope/"
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
" > < s:Body > <<br>
> > NotifyStateChanged xmlns = "<br>
> > <a moz-do-not-send="true"
href="http://dicom.nema.org/PS3.19/HostService-20100825"
target="_blank">http://dicom.nema.org/PS3.19/HostService-20100825</a>
" > < state > IDLE<br>
> > </ state > </
NotifyStateChanged > </ s:Body
> </ s:Envelope ><br>
> > Next, we tried changing
?newState? to ?state? but again it
fails<br>
> > when<br>
> > tried with the non-ctk based
host and producing the same error.<br>
> I think it is still either
related to the ":type" attribute or
the<br>
> error described below. Concerning
state/newState, please also see my<br>
> comments below.<br>
> > ...<br>
> > 2011-09-06 17:17:59,609
<faultstring xsi:type="xsd:string"<br>
> > xmlns:xsi="<br>
> > <a moz-do-not-send="true"
href="http://www.w3.org/1999/XMLSchema-instance"
target="_blank">http://www.w3.org/1999/XMLSchema-instance</a>
">The message with Action<br>
> > ''<br>
> > cannot be processed at the
receiver, due to a ContractFilter<br>
> > mismatch<br>
> > at the EndpointDispatcher.
This may be because of either a
contract<br>
> > mismatch (mismatched Actions
between sender and receiver) or a<br>
> > binding/security mismatch
between the sender and the receiver.
Check<br>
> > that sender and receiver
have the same contract and the same
binding<br>
> > (including security
requirements, e.g. Message, Transport,<br>
> > None).</faultstring>
...<br>
> This actually hints at a problem
concerning the action names. Looking<br>
> at the WSDL, the operation names
start with upper case latters, where<br>
> we are using lower case
(unfortunately, the text in the DICOM
Part 19<br>
> specs refer to the method names
with starting lower case letters).<br>
> > I even tried replacing the
WSDL files with the one provided by<br>
> > Non-CTK<br>
> > based host, but still it
doesn?t seem to work.<br>
> Yes, that does not change the
actual behavior.<br>
> > When looked at the code, I
noticed a comment in the CTK code
(below<br>
> > methods) ?spec would be
"state", java has "newState" FIX<br>
> > JAVA/STANDARD?. Could this
be something we need to look for? If
so<br>
> > may<br>
> > I know what would be the
change in Java side.<br>
> Unfortunately, again, the text in
the specs refer to "newState" for<br>
> the argument name and this is
what the XIP host is using. So we used<br>
> it too for testing with XIP. But
I agree that the WSDL should be the<br>
> definite guide and we should use
"state" when not testing with XIP.<br>
> My advice would be to keep your
modification ("newState" ->
"state")<br>
> and also try to modify the action
(method) names in<br>
> ctkDicomAppService.cpp (lines 40
- 60) to use upper case for the first<br>
> letter.<br>
> I would be happy if you could
keep us posted about your progress.<br>
> Thanks,<br>
> Sascha<br>
>
_______________________________________________<br>
> Ctk-developers mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Ctk-developers@commontk.org"
target="_blank">Ctk-developers@commontk.org</a><br>
> <a moz-do-not-send="true"
href="http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers"
target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers</a><br>
-------------- next part
--------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a moz-do-not-send="true"
href="http://public.kitware.com/pipermail/ctk-developers/attachments/20110908/e75bdbbd/attachment.htm"
target="_blank">http://public.kitware.com/pipermail/ctk-developers/attachments/20110908/e75bdbbd/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Ctk-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ctk-developers@commontk.org"
target="_blank">Ctk-developers@commontk.org</a><br>
<a moz-do-not-send="true"
href="http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers"
target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers</a><br>
<br>
<br>
End of Ctk-developers Digest, Vol 26,
Issue 6<br>
*********************************************<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>