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.<br>
<br>See <a href="https://secure.wikimedia.org/wikibooks/en/wiki/More_C%2B%2B_Idioms/Nifty_Counter">https://secure.wikimedia.org/wikibooks/en/wiki/More_C%2B%2B_Idioms/Nifty_Counter</a><br><br>Jc<br><br><div class="gmail_quote">
On Mon, Sep 19, 2011 at 12:19 PM, Sascha Zelzer <span dir="ltr"><<a href="mailto:s.zelzer@dkfz-heidelberg.de">s.zelzer@dkfz-heidelberg.de</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 bgcolor="#FFFFFF" text="#000000">
Hi Jc,<br>
<br>
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.<br>
<br>
Thanks,<br><font color="#888888">
Sascha</font><div><div></div><div class="h5"><br>
<br>
On 09/19/2011 05:19 PM, Jean-Christophe Fillion-Robin wrote:
<blockquote type="cite">Good catch ! <br>
<br>
For proper implementation of Singleton, you could refer to
ctkSingleton.h<br>
<br>
See <a href="https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h" target="_blank">https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h</a><br>
<br>
Thanks<br>
Jc<br>
<br>
<div class="gmail_quote">On Mon, Sep 19, 2011 at 10:31 AM, Sascha
Zelzer <span dir="ltr"><<a href="mailto:s.zelzer@dkfz-heidelberg.de" target="_blank">s.zelzer@dkfz-heidelberg.de</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 bgcolor="#FFFFFF" text="#000000"> You're welcome! Thanks
to you for your debugging efforts and detailed reports here.<br>
<font color="#888888"> <br>
-Sascha</font>
<div>
<div><br>
<br>
On 09/19/2011 04:18 PM, Anthony Dass wrote:
<blockquote type="cite">Hello Sascha,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Once again thank you very much!</div>
<div><br>
</div>
<div>Thanks,</div>
<div>~Anthony</div>
<div><br>
<div><br>
</div>
<div><br>
<br>
<div class="gmail_quote">On Mon, Sep 19, 2011 at
7:59 AM, Sascha Zelzer <span dir="ltr"><<a href="mailto:s.zelzer@dkfz-heidelberg.de" target="_blank">s.zelzer@dkfz-heidelberg.de</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 bgcolor="#ffffff" text="#000000"> 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>
<font color="#888888"> Sascha</font>
<div>
<div><br>
<br>
<br>
<br>
On 09/14/2011 03:24 AM, Anthony Dass
wrote:
<blockquote type="cite">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 href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
SOAP-ENV:encodingStyle="<a href="http://schemas.xmlsoap.org/soap/encoding/" target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>"
xmlns:xsd="htt<br>
p://<a href="http://www.w3.org/1999/XMLSchema" target="_blank">www.w3.org/1999/XMLSchema</a>"><br>
<SOAP-ENV:Body xmlns:SOAP-ENV="<a href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<setState xmlns="<a 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 href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
SOAP-ENV:encodingStyle="<a href="http://schemas.xmlsoap.org/soap/encoding/" target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>"
xml<br>
ns:xsd="<a href="http://www.w3.org/1999/XMLSchema" target="_blank">http://www.w3.org/1999/XMLSchema</a>"><br>
<SOAP-ENV:Body xmlns:SOAP-ENV="<a href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<SOAP-ENV:setState xmlns:SOAP-ENV="<a href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"><br>
<SOAP-ENV:setStateResponse
xmlns:SOAP-ENV="<a href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>"
xsi:type="xsd:boolean" xmlns:xsi="<a 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 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>
<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 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 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 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 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 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 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 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 href="mailto:s.zelzer@dkfz-heidelberg.de" target="_blank">s.zelzer@dkfz-heidelberg.de</a>><br>
Cc: Anthony Dass
<<a href="mailto:antdass@gmail.com" target="_blank">antdass@gmail.com</a>>,
<a href="mailto:ctk-developers@commontk.org" target="_blank">ctk-developers@commontk.org</a><br>
Message-ID:<br>
<<a 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 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 href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
"
SOAP-ENV:encodingStyle
=<br>
> > "<br>
> > <a href="http://schemas.xmlsoap.org/soap/encoding/" target="_blank">http://schemas.xmlsoap.org/soap/encoding/</a>
" xmlns:xsd = "<br>
> > <a 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 href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
" ><br>
> > <
notifyStateChanged
xmlns = " <a 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 href="http://schemas.xmlsoap.org/soap/envelope/" target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>
" > < s:Body
> <<br>
> >
NotifyStateChanged
xmlns = "<br>
> > <a 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 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 href="mailto:Ctk-developers@commontk.org" target="_blank">Ctk-developers@commontk.org</a><br>
> <a 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 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 href="mailto:Ctk-developers@commontk.org" target="_blank">Ctk-developers@commontk.org</a><br>
<a 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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Ctk-developers mailing list<br>
<a href="mailto:Ctk-developers@commontk.org" target="_blank">Ctk-developers@commontk.org</a><br>
<a 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>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<a href="tel:%2B1%20919%20869%208849" value="+19198698849" target="_blank">+1 919 869 8849</a><br>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>+1 919 869 8849<br><br>