From julien.finet at kitware.com Thu Sep 1 15:10:29 2011 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 1 Sep 2011 11:10:29 -0400 Subject: [Ctk-developers] Prefer to use normalized signal/slot signatures Message-ID: Information for Qt developers: http://marcmutz.wordpress.com/effective-qt/prefer-to-use-normalised-signalslot-signatures/ Regards, Julien. p.s. CTK and Slicer now use normalized signatures. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Sep 1 16:26:39 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 1 Sep 2011 12:26:39 -0400 Subject: [Ctk-developers] ctkUtils::rmdir - Delete recursively a directory Message-ID: Hi Folks, I was looking for a function to delete recursively a function and I found out that such code has present in multiple location: - ctkPluginFrameworkUtil_p.h - ctkPluginGenerator.cpp Topic "ctkutils-rmdir" has been integrated to master. It includes: - addition of "rmdir" function to ctkUtils - implementation of the corresponding test in ctkUtilsTest4.cpp - See https://github.com/commontk/CTK/commit/fd8cfead27c56ae607e379d764d2eb790d16af3e Topic "reuse-ctkutil-rmdir-in-toolkit" has NOT been integrated to master, indeed it implies that ctkPluginFramework will depend on CTKCore. Does that sounds reasonable ? See https://github.com/jcfr/CTK/tree/reuse-ctkutil-rmdir-in-toolkit and https://github.com/jcfr/CTK/commit/8714424163b376c4efb693448278a10e13a8690a Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Thu Sep 1 16:43:36 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 01 Sep 2011 18:43:36 +0200 Subject: [Ctk-developers] ctkUtils::rmdir - Delete recursively a directory In-Reply-To: References: Message-ID: <4E5FB638.3000800@dkfz-heidelberg.de> Hi Jc, Looks good. I guess the CTKCore dependency of the ctkPluginFramework was just a matter of time, so I am good with it. Just a little "style" comment: The "rmdir" function name looks a little out of place when compared with the others. What about "removeDir"? Just my two cents. Thanks for pushing code reuse, Sascha On 09/01/2011 06:26 PM, Jean-Christophe Fillion-Robin wrote: > Hi Folks, > > I was looking for a function to delete recursively a function and I > found out that such code has present in multiple location: > - ctkPluginFrameworkUtil_p.h > > - ctkPluginGenerator.cpp > > > Topic "ctkutils-rmdir" has been integrated to master. It includes: > - addition of "rmdir" function to ctkUtils > - implementation of the corresponding test in ctkUtilsTest4.cpp > - See > https://github.com/commontk/CTK/commit/fd8cfead27c56ae607e379d764d2eb790d16af3e > > Topic "reuse-ctkutil-rmdir-in-toolkit" has NOT been integrated to > master, indeed it implies that ctkPluginFramework will depend on > CTKCore. Does that sounds reasonable ? > See https://github.com/jcfr/CTK/tree/reuse-ctkutil-rmdir-in-toolkit > and > https://github.com/jcfr/CTK/commit/8714424163b376c4efb693448278a10e13a8690a > > Thanks > Jc > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Sep 1 16:55:51 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 1 Sep 2011 12:55:51 -0400 Subject: [Ctk-developers] ctkUtils::rmdir - Delete recursively a directory In-Reply-To: <4E5FB638.3000800@dkfz-heidelberg.de> References: <4E5FB638.3000800@dkfz-heidelberg.de> Message-ID: Hi Sasha, Since the Qt equivalent was named QDir::rmdir, I adopted the same name. Changing the name wouldn't be a problem. What about "removeDirRecusively" instead ? Jc On Thu, Sep 1, 2011 at 12:43 PM, Sascha Zelzer wrote: > Hi Jc, > > Looks good. I guess the CTKCore dependency of the ctkPluginFramework was > just a matter of time, so I am good with it. > > Just a little "style" comment: The "rmdir" function name looks a little out > of place when compared with the others. What about "removeDir"? Just my two > cents. > > Thanks for pushing code reuse, > > Sascha > > > On 09/01/2011 06:26 PM, Jean-Christophe Fillion-Robin wrote: > > Hi Folks, > > I was looking for a function to delete recursively a function and I found > out that such code has present in multiple location: > - ctkPluginFrameworkUtil_p.h > - ctkPluginGenerator.cpp > > Topic "ctkutils-rmdir" has been integrated to master. It includes: > - addition of "rmdir" function to ctkUtils > - implementation of the corresponding test in ctkUtilsTest4.cpp > - See > https://github.com/commontk/CTK/commit/fd8cfead27c56ae607e379d764d2eb790d16af3e > > Topic "reuse-ctkutil-rmdir-in-toolkit" has NOT been integrated to master, > indeed it implies that ctkPluginFramework will depend on CTKCore. Does that > sounds reasonable ? > See https://github.com/jcfr/CTK/tree/reuse-ctkutil-rmdir-in-toolkit > and > https://github.com/jcfr/CTK/commit/8714424163b376c4efb693448278a10e13a8690a > > Thanks > Jc > > > > -- > +1 919 869 8849 > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Thu Sep 1 17:44:21 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 01 Sep 2011 19:44:21 +0200 Subject: [Ctk-developers] ctkUtils::rmdir - Delete recursively a directory In-Reply-To: References: <4E5FB638.3000800@dkfz-heidelberg.de> Message-ID: <4E5FC475.9020802@dkfz-heidelberg.de> Even better! +1 [if you add an 'r' ;-) ] Thanks, Sascha On 09/01/2011 06:55 PM, Jean-Christophe Fillion-Robin wrote: > Hi Sasha, > > Since the Qt equivalent was named QDir::rmdir, I adopted the same > name. Changing the name wouldn't be a problem. > > What about "removeDirRecusively" instead ? > > Jc > > On Thu, Sep 1, 2011 at 12:43 PM, Sascha Zelzer > > wrote: > > Hi Jc, > > Looks good. I guess the CTKCore dependency of the > ctkPluginFramework was just a matter of time, so I am good with it. > > Just a little "style" comment: The "rmdir" function name looks a > little out of place when compared with the others. What about > "removeDir"? Just my two cents. > > Thanks for pushing code reuse, > > Sascha > > > On 09/01/2011 06:26 PM, Jean-Christophe Fillion-Robin wrote: >> Hi Folks, >> >> I was looking for a function to delete recursively a function and >> I found out that such code has present in multiple location: >> - ctkPluginFrameworkUtil_p.h >> >> - ctkPluginGenerator.cpp >> >> >> Topic "ctkutils-rmdir" has been integrated to master. It includes: >> - addition of "rmdir" function to ctkUtils >> - implementation of the corresponding test in ctkUtilsTest4.cpp >> - See >> https://github.com/commontk/CTK/commit/fd8cfead27c56ae607e379d764d2eb790d16af3e >> >> Topic "reuse-ctkutil-rmdir-in-toolkit" has NOT been integrated to >> master, indeed it implies that ctkPluginFramework will depend on >> CTKCore. Does that sounds reasonable ? >> See >> https://github.com/jcfr/CTK/tree/reuse-ctkutil-rmdir-in-toolkit >> and >> https://github.com/jcfr/CTK/commit/8714424163b376c4efb693448278a10e13a8690a >> >> Thanks >> Jc >> >> >> >> -- >> +1 919 869 8849 >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Thu Sep 1 21:33:31 2011 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 1 Sep 2011 17:33:31 -0400 Subject: [Ctk-developers] CTK now downloads dcmtk via git protocol Message-ID: CTK nowretrieves dcmtk using the git protocol. Kudos to Michael for adding the protocol on dcmtk servers. Remember, it's still possible to use the http protocol (set CTK_USE_GIT_PROTOCOL to false). Thanks, Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Sep 1 21:36:05 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 1 Sep 2011 17:36:05 -0400 Subject: [Ctk-developers] CTK now downloads dcmtk via git protocol In-Reply-To: References: Message-ID: Thanks Michael :) On Thu, Sep 1, 2011 at 5:33 PM, Julien Finet wrote: > CTK nowretrieves dcmtk using the git protocol. > Kudos to Michael for adding the protocol on dcmtk servers. > Remember, it's still possible to use the http protocol (set > CTK_USE_GIT_PROTOCOL to false). > > Thanks, > Julien. > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From antdass at gmail.com Tue Sep 6 22:22:53 2011 From: antdass at gmail.com (Anthony Dass) Date: Tue, 6 Sep 2011 18:22:53 -0400 Subject: [Ctk-developers] CTK based Hosted App fails when launched from Non-CTK Host Message-ID: -------------I'm re-sending this email since I got it bounced back. Hello, 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. 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. 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: *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).* 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: IDLE 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?. Here?s the example of the SOAP message generated by Non-CTK based HostedApp: IDLE Next, we tried changing ?newState? to ?state? but again it fails when tried with the non-ctk based host and producing the same error. *2011-09-06 17:17:52,234 New incoming connection * *2011-09-06 17:17:59,469 "* *2011-09-06 17:17:59,469 * *2011-09-06 17:17:59,485 * *2011-09-06 17:17:59,500 IDLE* *2011-09-06 17:17:59,500 * *2011-09-06 17:17:59,516 * *2011-09-06 17:17:59,516 * *2011-09-06 17:17:59,531 " * *2011-09-06 17:17:59,547 Submitted request "notifyStateChanged" * *2011-09-06 17:17:59,547 New incoming connection * *2011-09-06 17:17:59,563 New incoming connection * *2011-09-06 17:17:59,563 Response: "* *2011-09-06 17:17:59,578 * *2011-09-06 17:17:59,594 * *2011-09-06 17:17:59,594 a:ActionNotSupported* *2011-09-06 17:17:59,609 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).* *2011-09-06 17:17:59,625 * *2011-09-06 17:17:59,625 * *2011-09-06 17:17:59,641 * I even tried replacing the WSDL files with the one provided by Non-CTK based host, but still it doesn?t seem to work. 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. *void ctkDicomHostService::notifyStateChanged(ctkDicomAppHosting::State state)* *void ctkHostSoapMessageProcessor::processNotifyStateChanged( const QtSoapMessage &message, QtSoapMessage * /* reply */) const* Could you please advice? Thank you! ~Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Thu Sep 8 08:42:12 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 08 Sep 2011 10:42:12 +0200 Subject: [Ctk-developers] CTK based Hosted App fails when launched from Non-CTK Host In-Reply-To: References: Message-ID: <4E687FE4.7050608@dkfz-heidelberg.de> 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 foundout 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: > > *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).* > > 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: > > > > > > > > IDLE > > > > > > > > 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: > > > > > IDLE > > > > > 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 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)./ > > /.../ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Thu Sep 8 09:08:44 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 08 Sep 2011 11:08:44 +0200 Subject: [Ctk-developers] Clarification data handling - Application Hosting Support 118 In-Reply-To: <63D07F9AA364DB4C901F02EF93465C8D7808A545F6@USMLVA0E934MSX.ww017.siemens.net> References: <63D07F9AA364DB4C901F02EF93465C8D7808A545F6@USMLVA0E934MSX.ww017.siemens.net> Message-ID: <4E68861C.1080808@dkfz-heidelberg.de> Hi, When writing my reply to Anthony about the SOAP messages, I remembered that there was another mail pending from you guys. Sorry for letting it slip... Are those questions still relevant, or have you found the answers already? Best, Sascha On 06/14/2011 11:43 PM, Caylus, Michael (SCR US) wrote: > Hi all, > I have some uncertainties related to the data handling support in the > DICOM Support 118 specification: > In the file-based model in Figure 8.3.1 of spec; we can see that the > selection of Data is done though the Host. It is then the > responsibility of the application to pull information from the host > about the input data. > 1. Is it required to have any user interaction on the application to > request the data we want to retrieve? Can it happen automatically > right after processing the call of the notifyDataAvailable message ? > In the current example of the DICOM 118 support implemented in the CTK > SDK; I could see that the request of data is initiated from the user > through a mouse click on the button created by the application. I am > looking into a way to send a getData message without user interaction > so that basically the application shows directly the available data > selected on the host without any user interaction on the application. > I have tried to make a call to getData within the notifyDataAvailable > (ctkExampleDicomAppLogic) function but it looks like first the > notifyDataAvailable message need to be processed before making a > getData request. > 2. This leads me to a second question: Where should occur the > selection of Data? On the Host where the user define all the available > data and on the Application where we want to define which input Data > need to be retrieved depending of the available data? My first > intuition on this was that selection should only be done on the Host > but then I guess an extra notification is required so that the > application knows that the notifyDataAvailable message has been fully > process. > Best, > Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.bleuze at inria.fr Thu Sep 8 10:46:30 2011 From: benoit.bleuze at inria.fr (Benoit Bleuze) Date: Thu, 8 Sep 2011 12:46:30 +0200 (CEST) Subject: [Ctk-developers] CTK based Hosted App fails when launched from Non-CTK Host In-Reply-To: <4E687FE4.7050608@dkfz-heidelberg.de> Message-ID: <610925954.61455.1315478790178.JavaMail.root@zmbs4.inria.fr> 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). > > 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 > > > > > > > > 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 > > > > 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 > 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). ... > 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: From s.zelzer at dkfz-heidelberg.de Thu Sep 8 15:09:24 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 08 Sep 2011 17:09:24 +0200 Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest Message-ID: <4E68DAA4.5090308@dkfz-heidelberg.de> Hi guys, During the last weeks - with the next hackfest in mind - I was thinking about how to advance the state of our DICOM Part 19 implementation. Using the current mails about this topic as a motivator, I'd like to get a little organized up front. First of all, I would like to know how many people are interested in working on this topic during the hackfest (I'm sure Benoit is in ;-) ). Maybe we can also identify other topics so people can get a little organized before the hackfest. For the DICOM Application Hosting, I would like to see something in the direction of a "conformance test suite". Meaning, some tools which make testing and diagnosing of our own implementation and others far easier. This could drive our work on implementing more of the specs and help others check "DICOM Part 19 conformance". If people are in line with these ideas, I would start thinking about the test set-up itself, such that we can implement specific tests (state transitions, data exchange tests, etc.) during the hackfest which could in parallel guide our implementation efforts. Thanks, Sascha From dicom at offis.de Thu Sep 8 15:54:49 2011 From: dicom at offis.de (OFFIS DICOM Team) Date: Thu, 08 Sep 2011 17:54:49 +0200 Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest In-Reply-To: <4E68DAA4.5090308@dkfz-heidelberg.de> References: <4E68DAA4.5090308@dkfz-heidelberg.de> Message-ID: <4E68E549.8020206@offis.de> Dear Sascha and everybody, On 08.09.2011 17:09, Sascha Zelzer wrote: > First of all, I would like to know how many people are interested in > working on this topic during the hackfest (I'm sure Benoit is in ;-) > ). Maybe we can also identify other topics so people can get a little > organized before the hackfest. Thanks Sascha for starting organizing things and people _before_ November :-) I would be happy to join the app hosting work during the hackfest, if this makes sense. I would more look on the lower level parts that I would see in DCMTK, e.g. working on fast access into DICOM data in order to respond to incoming XPath queries. > For the DICOM Application Hosting, I would like to see something in > the direction of a "conformance test suite". Meaning, some tools > which make testing and diagnosing of our own implementation and > others far easier. This could drive our work on implementing more of > the specs and help others check "DICOM Part 19 conformance". I support this idea; since there are not too many implementations so far I would expect that these are mainly tests for ourselves now -- however this is in fact necessary ;) And will foster further implementations, indeed. Other DICOM things that I have in mind for the hackfest (or hopefully even before) are - a decent FindDCMTK.cmake (I know you are waiting for this) - adding DCMTK's latest C-GET support to CTK's Query/Retrieve code. The latter would include an update to the latest DCMTK. C-GET would permit retrieving images without starting an extra storage server, i.e. making it also easier to handle the incoming data (indexing, continuing with workflow, etc) if the PACS supports C-GET communication. There are also further things that could be improved in the Q/R area. Greetings from Brussels, Michael -- OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany E-Mail: dicom at offis.de, URL: http://dicom.offis.de From antdass at gmail.com Thu Sep 8 23:18:09 2011 From: antdass at gmail.com (Anthony Dass) Date: Thu, 8 Sep 2011 19:18:09 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: Message-ID: 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, 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 > Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched > from Non-CTK Host > To: Sascha Zelzer > Cc: Anthony Dass , 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). > > > 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 > > > > > > > > > > > > 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 > > > > > > 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 > > 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). ... > > 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: From s.zelzer at dkfz-heidelberg.de Fri Sep 9 08:26:56 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Fri, 09 Sep 2011 10:26:56 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: Message-ID: <4E69CDD0.4090807@dkfz-heidelberg.de> Hi, On 09/09/2011 01:18 AM, Anthony Dass wrote: > 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. I had a look at the messages yesterday and could actually not reproduce your problem with the missing namespace (the messages between the CTK host and CTK app looked correct). I also looked at the QtSoap code and could not spot a problem at first sight. Best, Sascha > > thank you very much! > /Anthony > > > On Thu, Sep 8, 2011 at 6:47 AM, > 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 > > Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched > from Non-CTK Host > To: Sascha Zelzer > > Cc: Anthony Dass >, > 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). > > > 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 > > > > > > > > > > > > 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 > > > > > > 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 > > 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). ... > > 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: > > > ------------------------------ > > _______________________________________________ > 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: From s.zelzer at dkfz-heidelberg.de Fri Sep 9 08:28:46 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Fri, 09 Sep 2011 10:28:46 +0200 Subject: [Ctk-developers] Clarification data handling - Application Hosting Support 118 In-Reply-To: <21122A23A210AC4598D89FAC10F6A3621BC5C845FE@USLZUA0E925MSX.ww017.siemens.net> References: <63D07F9AA364DB4C901F02EF93465C8D7808A545F6@USMLVA0E934MSX.ww017.siemens.net> <4E68861C.1080808@dkfz-heidelberg.de> <21122A23A210AC4598D89FAC10F6A3621BC5C845FE@USLZUA0E925MSX.ww017.siemens.net> Message-ID: <4E69CE3E.9040402@dkfz-heidelberg.de> Hi Anthony, Good to know and thanks for sharing your solution. Best, Sascha On 09/09/2011 01:49 AM, Sowrirajan, Anthony Dass (SCR US) wrote: > > Hi Sascha, > > Thank you very much for your answers and remembering this issue. > > Yes, we managed to get it resolved from our application side. Once the > app receives a notification of data available from Host, it remembers > this information and upon successful launch of application it > attempts to get the data. This way the app automatically loads the > data without user intervention. Earlier we had this issue because we > attempted to get the data as soon as we get the notification of data > available and since it was a blocking call it never returned. Now, it > works and we see the data loading as soon as the app is launched. > > Once again thank you very much for asking. > > Thank you! > > /Anthony > > *From:*Sascha Zelzer [mailto:s.zelzer at dkfz-heidelberg.de] > *Sent:* Thursday, September 08, 2011 5:09 AM > *To:* Caylus, Michael (SCR US) > *Cc:* ctk-developers at commontk.org; Ljung, Patric (SCR US); Odry, > Benjamin (SCR US); Sowrirajan, Anthony Dass (SCR US) > *Subject:* Re: [Ctk-developers] Clarification data handling - > Application Hosting Support 118 > > Hi, > > When writing my reply to Anthony about the SOAP messages, I remembered > that there was another mail pending from you guys. Sorry for letting > it slip... > > Are those questions still relevant, or have you found the answers already? > > Best, > Sascha > > On 06/14/2011 11:43 PM, Caylus, Michael (SCR US) wrote: > > Hi all, > > I have some uncertainties related to the data handling support in the > DICOM Support 118 specification: > > In the file-based model in Figure 8.3.1 of spec; we can see that the > selection of Data is done though the Host. It is then the > responsibility of the application to pull information from the host > about the input data. > > 1. Is it required to have any user interaction on the application to > request the data we want to retrieve? Can it happen automatically > right after processing the call of the notifyDataAvailable message ? > In the current example of the DICOM 118 support implemented in the CTK > SDK; I could see that the request of data is initiated from the user > through a mouse click on the button created by the application. I am > looking into a way to send a getData message without user interaction > so that basically the application shows directly the available data > selected on the host without any user interaction on the application. > I have tried to make a call to getData within the notifyDataAvailable > (ctkExampleDicomAppLogic) function but it looks like first the > notifyDataAvailable message need to be processed before making a > getData request. > > 2. This leads me to a second question: Where should occur the > selection of Data? On the Host where the user define all the available > data and on the Application where we want to define which input Data > need to be retrieved depending of the available data? My first > intuition on this was that selection should only be done on the Host > but then I guess an extra notification is required so that the > application knows that the notifyDataAvailable message has been fully > process. > > Best, > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.bleuze at inria.fr Fri Sep 9 08:36:17 2011 From: benoit.bleuze at inria.fr (Benoit Bleuze) Date: Fri, 9 Sep 2011 10:36:17 +0200 (CEST) Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest In-Reply-To: <4E68E549.8020206@offis.de> Message-ID: <457000924.76943.1315557377176.JavaMail.root@zmbs4.inria.fr> First, of course I am on board! Then concerning Sascha's proposition of a test suite, given the blurry implementations everyone has, this is definitely a must, and perhaps Siemens people have already done something in that direction. If so we can build on it, otherwise we'll have to do it ourselves from scratch. Do you have any idea where to start? I would like to get the WSDL file correct once and for all: differences in the action casing is unacceptable (if the parsing is case dependent). Sending models to efficiently serve volumes in slices is something we haven't touched at all yet, but Michael it is indeed very much exciting. Just be aware that it looks like to get something working you need a lot of work, so don't expect to finish it in a week. That said it could be a good spring board to get it started. - A cleaner, more robust findDCMTK... we'd like that ;-). By the way at INRIA, we have some tiny updates to the 3.6 findDCMTK, I should send you a patch for it, as well as a few updates for Mac OsX compilation. I'll leave the rest of the dicom support to the better qualified Dicom people. Ben ----- Original Message ----- > Dear Sascha and everybody, > > On 08.09.2011 17:09, Sascha Zelzer wrote: > > > First of all, I would like to know how many people are interested in > > working on this topic during the hackfest (I'm sure Benoit is in ;-) > > ). Maybe we can also identify other topics so people can get a > > little > > organized before the hackfest. > > Thanks Sascha for starting organizing things and people _before_ > November :-) I would be happy to join the app hosting work during the > hackfest, if this makes sense. I would more look on the lower level > parts that I would see in DCMTK, e.g. working on fast access into > DICOM > data in order to respond to incoming XPath queries. > > > For the DICOM Application Hosting, I would like to see something in > > the direction of a "conformance test suite". Meaning, some tools > > which make testing and diagnosing of our own implementation and > > others far easier. This could drive our work on implementing more of > > the specs and help others check "DICOM Part 19 conformance". > > I support this idea; since there are not too many implementations so > far > I would expect that these are mainly tests for ourselves now -- > however > this is in fact necessary ;) And will foster further implementations, > indeed. > > Other DICOM things that I have in mind for the hackfest (or hopefully > even before) are > - a decent FindDCMTK.cmake (I know you are waiting for this) > - adding DCMTK's latest C-GET support to CTK's Query/Retrieve code. > > The latter would include an update to the latest DCMTK. C-GET would > permit retrieving images without starting an extra storage > server, i.e. making it also easier to handle the incoming data > (indexing, continuing with workflow, etc) if the PACS supports C-GET > communication. There are also further things that could be improved in > the Q/R area. > > Greetings from Brussels, > Michael > > -- > OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany > E-Mail: dicom at offis.de, URL: http://dicom.offis.de > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From benoit.bleuze at inria.fr Fri Sep 9 08:31:18 2011 From: benoit.bleuze at inria.fr (Benoit Bleuze) Date: Fri, 9 Sep 2011 10:31:18 +0200 (CEST) Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: Message-ID: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> 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... ----- Original Message ----- > 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). > > > > 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 > > > > > > > > > > > > > > > > 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 > > > > > > > > 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 > > > 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). ... > > > 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: From pieper at ibility.net Fri Sep 9 12:22:13 2011 From: pieper at ibility.net (Steve Pieper) Date: Fri, 9 Sep 2011 08:22:13 -0400 Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest In-Reply-To: <457000924.76943.1315557377176.JavaMail.root@zmbs4.inria.fr> References: <4E68E549.8020206@offis.de> <457000924.76943.1315557377176.JavaMail.root@zmbs4.inria.fr> Message-ID: Hi Guys - I'm in for the hackfest too - very much looking forward to it! I'd like to work with Michael (and others!) on the C-GET and also on fleshing out the DcmSCP and DcmSCU code to serve as the guts of our ctkDICOM code. We're starting to make use of the ctkDICOM code in slicer so there is some good practical stuff to sort out. Best, -Steve On Fri, Sep 9, 2011 at 4:36 AM, Benoit Bleuze wrote: > First, of course I am on board! > Then concerning Sascha's proposition of a test suite, given the blurry > implementations everyone has, this is definitely a must, and perhaps Siemens > people have already done something in that direction. > If so we can build on it, otherwise we'll have to do it ourselves from > scratch. Do you have any idea where to start? I would like to get the WSDL > file correct once and for all: differences in the action casing is > unacceptable (if the parsing is case dependent). > > Sending models to efficiently serve volumes in slices is something we > haven't touched at all yet, but Michael it is indeed very much exciting. > Just be aware that it looks like to get something working you need a lot of > work, so don't expect to finish it in a week. That said it could be a good > spring board to get it started. > > > - A cleaner, more robust findDCMTK... we'd like that ;-). By the way at > INRIA, we have some tiny updates to the 3.6 findDCMTK, I should send you a > patch for it, as well as a few updates for Mac OsX compilation. > I'll leave the rest of the dicom support to the better qualified Dicom > people. > > Ben > > ----- Original Message ----- > > Dear Sascha and everybody, > > > > On 08.09.2011 17:09, Sascha Zelzer wrote: > > > > > First of all, I would like to know how many people are interested in > > > working on this topic during the hackfest (I'm sure Benoit is in ;-) > > > ). Maybe we can also identify other topics so people can get a > > > little > > > organized before the hackfest. > > > > Thanks Sascha for starting organizing things and people _before_ > > November :-) I would be happy to join the app hosting work during the > > hackfest, if this makes sense. I would more look on the lower level > > parts that I would see in DCMTK, e.g. working on fast access into > > DICOM > > data in order to respond to incoming XPath queries. > > > > > For the DICOM Application Hosting, I would like to see something in > > > the direction of a "conformance test suite". Meaning, some tools > > > which make testing and diagnosing of our own implementation and > > > others far easier. This could drive our work on implementing more of > > > the specs and help others check "DICOM Part 19 conformance". > > > > I support this idea; since there are not too many implementations so > > far > > I would expect that these are mainly tests for ourselves now -- > > however > > this is in fact necessary ;) And will foster further implementations, > > indeed. > > > > Other DICOM things that I have in mind for the hackfest (or hopefully > > even before) are > > - a decent FindDCMTK.cmake (I know you are waiting for this) > > - adding DCMTK's latest C-GET support to CTK's Query/Retrieve code. > > > > The latter would include an update to the latest DCMTK. C-GET would > > permit retrieving images without starting an extra storage > > server, i.e. making it also easier to handle the incoming data > > (indexing, continuing with workflow, etc) if the PACS supports C-GET > > communication. There are also further things that could be improved in > > the Q/R area. > > > > Greetings from Brussels, > > Michael > > > > -- > > OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany > > E-Mail: dicom at offis.de, URL: http://dicom.offis.de > > _______________________________________________ > > Ctk-developers mailing list > > Ctk-developers at commontk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > _______________________________________________ > 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: From stephen.aylward at kitware.com Sun Sep 11 02:32:06 2011 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sat, 10 Sep 2011 22:32:06 -0400 Subject: [Ctk-developers] A more general discussion on the CTK at MICCAI 2011? In-Reply-To: <1771382181.3444715.1309611517022.JavaMail.root@zmbs3.inria.fr> References: <4E0DF9ED.5090209@bwh.harvard.edu> <1771382181.3444715.1309611517022.JavaMail.root@zmbs3.inria.fr> Message-ID: Hi, Looking forward to our meeting during lunch on Monday at MICCAI for a CTK talkfest. I'd like to get a headcount - please reply if you can attend. Thanks, Stephen On Sat, Jul 2, 2011 at 8:58 AM, Maxime Sermesant wrote: >> We could do an informal meeting during lunch on Monday? > > that's good for me. > > best, > > -- > > ?Maxime > > >> On 7/1/11 12:18 PM, Maxime Sermesant wrote: >> > Hello, >> > >> > There is already an open source meeting on the night of the first >> > workshop day, so the organisers told me to organise the CTK >> > discussion on the night of the last workshop day (22th of >> > September). They are not in favour of having other events during the >> > 3 main conference days :-| >> > >> > However I am afraid people will start travelling back after one week >> > of MICCAI. >> > >> > So I can try to ask again (or someone with more influence ;) or we >> > can do that independently whether during one lunch or one night, >> > because we may not really need a meeting room facilities for such >> > discussion. >> > >> > Let me know your preferred option. >> > >> > (I can already guarantee you a room for a CTK meeting at next year's >> > MICCAI in Nice ;) >> > >> > Best, >> > >> > -- >> > >> > ? ?Maxime >> > >> > >> > PS: the other meeting webpage: >> > https://www.assembla.com/spaces/sparkit/wiki/OCAIRO-SparKit_technical_meeting_at_MICCAI >> > >> > >> > ----- Original Message ----- >> >> From: "Ron Kikinis" >> >> To: ctk-developers at commontk.org >> >> Sent: Friday, 1 July, 2011 2:27:31 PM >> >> Subject: Re: [Ctk-developers] A more general discussion on the CTK >> >> at MICCAI 2011? >> >> >> >> This is for lunch? >> >> >> >> On 5/27/2011 7:17 AM, Maxime Sermesant wrote: >> >>> Dear all, >> >>> >> >>> I can see with a local organiser to get a room (for around 20 >> >>> people?) probably the 19th of September (the conference diner is >> >>> usually on the second night, thus the 20th) at around 6:30 pm (the >> >>> program is not online yet). Let me know if you already know of >> >>> other meetings that would conflict with this one (I don't have the >> >>> MICCAI board schedule for instance). >> >>> >> >>> PS: I (obviously) don't feel in any particular position in order >> >>> to >> >>> propose an agenda for the meeting and animate the discussion, and >> >>> there will be CTK members better suited to do that, so I will >> >>> limit my role to the logistics. >> >>> >> >>> Best wishes, >> >>> >> >>> -- >> >>> >> >>> ? ? Maxime >> >>> >> >>> ----- Original Message ----- >> >>>> From: "Hans-Peter Meinzer" >> >>>> To: "Gianluca Paladini (SCR US)", >> >>>> "Maxime Sermesant", >> >>>> ctk-developers at commontk.org >> >>>> Cc: "Alejandro Frangi" >> >>>> Sent: Friday, 27 May, 2011 1:06:38 PM >> >>>> Subject: AW: [Ctk-developers] A more general discussion on the >> >>>> CTK >> >>>> at MICCAI 2011? >> >>>> >> >>>> Ok. I will be also in Toronto. Can somebody organize a meeting >> >>>> room?. >> >>>> Best wishes from Heidelberg Peter Meinzer >> >>>> >> >>>> -----Urspr?ngliche Nachricht----- >> >>>> Von: ctk-developers-bounces at commontk.org >> >>>> [mailto:ctk-developers-bounces at commontk.org] Im Auftrag von >> >>>> Paladini, Gianluca (SCR US) >> >>>> Gesendet: Freitag, 27. Mai 2011 05:08 >> >>>> An: Maxime Sermesant; ctk-developers at commontk.org >> >>>> Cc: Alejandro Frangi >> >>>> Betreff: Re: [Ctk-developers] A more general discussion on the >> >>>> CTK >> >>>> at >> >>>> MICCAI 2011? >> >>>> >> >>>> Good idea, we haven't had committee/administrative meetings since >> >>>> 2009 and only one planning meeting at SPIE San Diego in 2010. >> >>>> MICCAI 2011 is a good opportunity, please count me in. >> >>>> Cordially, >> >>>> ? ? ? Gianluca >> >>>> >> >>>> -----Original Message----- >> >>>> From: ctk-developers-bounces at commontk.org >> >>>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Maxime >> >>>> Sermesant >> >>>> Sent: Thursday, May 26, 2011 10:35 AM >> >>>> To: ctk-developers at commontk.org >> >>>> Cc: Alejandro Frangi >> >>>> Subject: [Ctk-developers] A more general discussion on the CTK at >> >>>> MICCAI 2011? >> >>>> >> >>>> Dear all, >> >>>> >> >>>> within the discussions around imaging software at the European >> >>>> level >> >>>> (e.g. in the VPH Network of Excellence) there was a point raised >> >>>> regarding the general directions that the CTK is following, and >> >>>> how/when this is/could be discussed. I know that the CTK is >> >>>> currently mostly code-oriented, with the hackfests being its main >> >>>> concrete activity, but it would probably be helpful for all the >> >>>> involved partners to get an opportunity to discuss on the more >> >>>> global level. >> >>>> >> >>>> As Alex Frangi (in CC, who was also primarily interested by such >> >>>> discussion), myself and many others will be in Toronto this >> >>>> September for MICCAI 2011, maybe there could be an opportunity >> >>>> there >> >>>> to have a more high-level CTK meeting? >> >>>> >> >>>> I could also easily include such meeting in the hackfest >> >>>> happening >> >>>> at >> >>>> INRIA, but I am not sure if people interested in the discussion >> >>>> but >> >>>> not in the hackfest would then travel (understandably). >> >>>> >> >>>> Let me know if you are interested, so that I contact the MICCAI >> >>>> organisers to try to get a room for that if there is enough >> >>>> interest. >> >>>> >> >>>> Best wishes, >> >>>> >> >>>> -- >> >>>> >> >>>> ? ? Maxime >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ctk-developers mailing list >> >>>> Ctk-developers at commontk.org >> >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >>>> _______________________________________________ >> >>>> Ctk-developers mailing list >> >>>> Ctk-developers at commontk.org >> >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >>>> >> >>> _______________________________________________ >> >>> Ctk-developers mailing list >> >>> Ctk-developers at commontk.org >> >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> >> >> -- >> >> Ron Kikinis, M.D., >> >> Robert Greenes Distinguished Director of Biomedical Informatics >> >> Professor of Radiology, Harvard Medical School >> >> Director, Surgical Planning Laboratory >> >> http://www.spl.harvard.edu/~kikinis >> >> _______________________________________________ >> >> Ctk-developers mailing list >> >> Ctk-developers at commontk.org >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> -- >> Ron Kikinis, M.D., >> Robert Greenes Distinguished Director of Biomedical Informatics >> Professor of Radiology, Harvard Medical School >> Director, Surgical Planning Laboratory >> http://www.spl.harvard.edu/~kikinis > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- ============================== Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From kikinis at bwh.harvard.edu Sun Sep 11 04:11:15 2011 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Sun, 11 Sep 2011 00:11:15 -0400 Subject: [Ctk-developers] A more general discussion on the CTK at MICCAI 2011? In-Reply-To: References: <4E0DF9ED.5090209@bwh.harvard.edu> <1771382181.3444715.1309611517022.JavaMail.root@zmbs3.inria.fr> Message-ID: <4E6C34E3.2040400@bwh.harvard.edu> I will. On 9/10/11 10:32 PM, Stephen Aylward wrote: > Hi, > > Looking forward to our meeting during lunch on Monday at MICCAI for a > CTK talkfest. > > I'd like to get a headcount - please reply if you can attend. > > Thanks, > Stephen > > On Sat, Jul 2, 2011 at 8:58 AM, Maxime Sermesant > wrote: >>> We could do an informal meeting during lunch on Monday? >> >> that's good for me. >> >> best, >> >> -- >> >> Maxime >> >> >>> On 7/1/11 12:18 PM, Maxime Sermesant wrote: >>>> Hello, >>>> >>>> There is already an open source meeting on the night of the first >>>> workshop day, so the organisers told me to organise the CTK >>>> discussion on the night of the last workshop day (22th of >>>> September). They are not in favour of having other events during the >>>> 3 main conference days :-| >>>> >>>> However I am afraid people will start travelling back after one week >>>> of MICCAI. >>>> >>>> So I can try to ask again (or someone with more influence ;) or we >>>> can do that independently whether during one lunch or one night, >>>> because we may not really need a meeting room facilities for such >>>> discussion. >>>> >>>> Let me know your preferred option. >>>> >>>> (I can already guarantee you a room for a CTK meeting at next year's >>>> MICCAI in Nice ;) >>>> >>>> Best, >>>> >>>> -- >>>> >>>> Maxime >>>> >>>> >>>> PS: the other meeting webpage: >>>> https://www.assembla.com/spaces/sparkit/wiki/OCAIRO-SparKit_technical_meeting_at_MICCAI >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Ron Kikinis" >>>>> To: ctk-developers at commontk.org >>>>> Sent: Friday, 1 July, 2011 2:27:31 PM >>>>> Subject: Re: [Ctk-developers] A more general discussion on the CTK >>>>> at MICCAI 2011? >>>>> >>>>> This is for lunch? >>>>> >>>>> On 5/27/2011 7:17 AM, Maxime Sermesant wrote: >>>>>> Dear all, >>>>>> >>>>>> I can see with a local organiser to get a room (for around 20 >>>>>> people?) probably the 19th of September (the conference diner is >>>>>> usually on the second night, thus the 20th) at around 6:30 pm (the >>>>>> program is not online yet). Let me know if you already know of >>>>>> other meetings that would conflict with this one (I don't have the >>>>>> MICCAI board schedule for instance). >>>>>> >>>>>> PS: I (obviously) don't feel in any particular position in order >>>>>> to >>>>>> propose an agenda for the meeting and animate the discussion, and >>>>>> there will be CTK members better suited to do that, so I will >>>>>> limit my role to the logistics. >>>>>> >>>>>> Best wishes, >>>>>> >>>>>> -- >>>>>> >>>>>> Maxime >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Hans-Peter Meinzer" >>>>>>> To: "Gianluca Paladini (SCR US)", >>>>>>> "Maxime Sermesant", >>>>>>> ctk-developers at commontk.org >>>>>>> Cc: "Alejandro Frangi" >>>>>>> Sent: Friday, 27 May, 2011 1:06:38 PM >>>>>>> Subject: AW: [Ctk-developers] A more general discussion on the >>>>>>> CTK >>>>>>> at MICCAI 2011? >>>>>>> >>>>>>> Ok. I will be also in Toronto. Can somebody organize a meeting >>>>>>> room?. >>>>>>> Best wishes from Heidelberg Peter Meinzer >>>>>>> >>>>>>> -----Urspr?ngliche Nachricht----- >>>>>>> Von: ctk-developers-bounces at commontk.org >>>>>>> [mailto:ctk-developers-bounces at commontk.org] Im Auftrag von >>>>>>> Paladini, Gianluca (SCR US) >>>>>>> Gesendet: Freitag, 27. Mai 2011 05:08 >>>>>>> An: Maxime Sermesant; ctk-developers at commontk.org >>>>>>> Cc: Alejandro Frangi >>>>>>> Betreff: Re: [Ctk-developers] A more general discussion on the >>>>>>> CTK >>>>>>> at >>>>>>> MICCAI 2011? >>>>>>> >>>>>>> Good idea, we haven't had committee/administrative meetings since >>>>>>> 2009 and only one planning meeting at SPIE San Diego in 2010. >>>>>>> MICCAI 2011 is a good opportunity, please count me in. >>>>>>> Cordially, >>>>>>> Gianluca >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ctk-developers-bounces at commontk.org >>>>>>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Maxime >>>>>>> Sermesant >>>>>>> Sent: Thursday, May 26, 2011 10:35 AM >>>>>>> To: ctk-developers at commontk.org >>>>>>> Cc: Alejandro Frangi >>>>>>> Subject: [Ctk-developers] A more general discussion on the CTK at >>>>>>> MICCAI 2011? >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> within the discussions around imaging software at the European >>>>>>> level >>>>>>> (e.g. in the VPH Network of Excellence) there was a point raised >>>>>>> regarding the general directions that the CTK is following, and >>>>>>> how/when this is/could be discussed. I know that the CTK is >>>>>>> currently mostly code-oriented, with the hackfests being its main >>>>>>> concrete activity, but it would probably be helpful for all the >>>>>>> involved partners to get an opportunity to discuss on the more >>>>>>> global level. >>>>>>> >>>>>>> As Alex Frangi (in CC, who was also primarily interested by such >>>>>>> discussion), myself and many others will be in Toronto this >>>>>>> September for MICCAI 2011, maybe there could be an opportunity >>>>>>> there >>>>>>> to have a more high-level CTK meeting? >>>>>>> >>>>>>> I could also easily include such meeting in the hackfest >>>>>>> happening >>>>>>> at >>>>>>> INRIA, but I am not sure if people interested in the discussion >>>>>>> but >>>>>>> not in the hackfest would then travel (understandably). >>>>>>> >>>>>>> Let me know if you are interested, so that I contact the MICCAI >>>>>>> organisers to try to get a room for that if there is enough >>>>>>> interest. >>>>>>> >>>>>>> Best wishes, >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Maxime >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> _______________________________________________ >>>>>>> Ctk-developers mailing list >>>>>>> Ctk-developers at commontk.org >>>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>>>> >>>>>> _______________________________________________ >>>>>> Ctk-developers mailing list >>>>>> Ctk-developers at commontk.org >>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>>> >>>>> -- >>>>> Ron Kikinis, M.D., >>>>> Robert Greenes Distinguished Director of Biomedical Informatics >>>>> Professor of Radiology, Harvard Medical School >>>>> Director, Surgical Planning Laboratory >>>>> http://www.spl.harvard.edu/~kikinis >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>> >>> -- >>> Ron Kikinis, M.D., >>> Robert Greenes Distinguished Director of Biomedical Informatics >>> Professor of Radiology, Harvard Medical School >>> Director, Surgical Planning Laboratory >>> http://www.spl.harvard.edu/~kikinis >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > > -- Ron Kikinis, M.D., Robert Greenes Distinguished Director of Biomedical Informatics Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From s.zelzer at dkfz-heidelberg.de Sun Sep 11 12:03:46 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Sun, 11 Sep 2011 14:03:46 +0200 Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest In-Reply-To: References: <4E68DAA4.5090308@dkfz-heidelberg.de> Message-ID: <4E6CA3A2.90601@dkfz-heidelberg.de> Hi, Thanks to Larry for pointing out DVTk. Reusing or extending an existing validation framework should definitely be considered. It seems that DVTk is Windows only (even tied to Visual Studio as an IDE) but I will check it out in more detail. If anybody else knows of a validation framework which would suit our needs, I'd be happy to hear about it. I will start adding names of people who expressed their interest in working on app hosting during the hackfest on the Wiki, if that's okay. Thanks, Sascha On 09/10/2011 09:13 PM, Tarbox, Lawrence wrote: > Regarding conformance testing, many people used DVTK to test conformance against the DICOM standard (see http://www.dvtk.com). Would it be appropriate to extend DVTK with Application Hosting testing, instead of rolling our own test framework? We might get broader user acceptance that way. > > Lawrence > > -----Original Message----- > From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Sascha Zelzer > Sent: Thursday, September 08, 2011 10:09 AM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest > > Hi guys, > > During the last weeks - with the next hackfest in mind - I was thinking about how to advance the state of our DICOM Part 19 implementation. > Using the current mails about this topic as a motivator, I'd like to get a little organized up front. > > First of all, I would like to know how many people are interested in working on this topic during the hackfest (I'm sure Benoit is in ;-) ). > Maybe we can also identify other topics so people can get a little organized before the hackfest. > > For the DICOM Application Hosting, I would like to see something in the direction of a "conformance test suite". Meaning, some tools which make testing and diagnosing of our own implementation and others far easier. > This could drive our work on implementing more of the specs and help others check "DICOM Part 19 conformance". > > If people are in line with these ideas, I would start thinking about the test set-up itself, such that we can implement specific tests (state transitions, data exchange tests, etc.) during the hackfest which could in parallel guide our implementation efforts. > > Thanks, > > Sascha > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > ________________________________ > > The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From pieper at ibility.net Sun Sep 11 14:55:24 2011 From: pieper at ibility.net (Steve Pieper) Date: Sun, 11 Sep 2011 10:55:24 -0400 Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis Hackfest In-Reply-To: <4E6CA3A2.90601@dkfz-heidelberg.de> References: <4E68DAA4.5090308@dkfz-heidelberg.de> <4E6CA3A2.90601@dkfz-heidelberg.de> Message-ID: Hi Sascha - There's a skeleton hackfest page here - feel free to flesh it out with more project info: http://www.commontk.org/index.php/CTK-Hackfest-Nov-2011 thanks, Steve On Sun, Sep 11, 2011 at 8:03 AM, Sascha Zelzer wrote: > Hi, > > Thanks to Larry for pointing out DVTk. Reusing or extending an existing > validation framework should definitely be considered. It seems that DVTk is > Windows only (even tied to Visual Studio as an IDE) but I will check it out > in more detail. > > If anybody else knows of a validation framework which would suit our needs, > I'd be happy to hear about it. > > I will start adding names of people who expressed their interest in working > on app hosting during the hackfest on the Wiki, if that's okay. > > Thanks, > > Sascha > > On 09/10/2011 09:13 PM, Tarbox, Lawrence wrote: > >> Regarding conformance testing, many people used DVTK to test conformance >> against the DICOM standard (see http://www.dvtk.com). Would it be >> appropriate to extend DVTK with Application Hosting testing, instead of >> rolling our own test framework? We might get broader user acceptance that >> way. >> >> Lawrence >> >> >> -----Original Message----- >> From: ctk-developers-bounces@**commontk.org[mailto: >> ctk-developers-**bounces at commontk.org] >> On Behalf Of Sascha Zelzer >> Sent: Thursday, September 08, 2011 10:09 AM >> To: ctk-developers at commontk.org >> Subject: [Ctk-developers] DICOM Application Hosting / Sophia-Antipolis >> Hackfest >> >> Hi guys, >> >> During the last weeks - with the next hackfest in mind - I was thinking >> about how to advance the state of our DICOM Part 19 implementation. >> Using the current mails about this topic as a motivator, I'd like to get a >> little organized up front. >> >> First of all, I would like to know how many people are interested in >> working on this topic during the hackfest (I'm sure Benoit is in ;-) ). >> Maybe we can also identify other topics so people can get a little >> organized before the hackfest. >> >> For the DICOM Application Hosting, I would like to see something in the >> direction of a "conformance test suite". Meaning, some tools which make >> testing and diagnosing of our own implementation and others far easier. >> This could drive our work on implementing more of the specs and help >> others check "DICOM Part 19 conformance". >> >> If people are in line with these ideas, I would start thinking about the >> test set-up itself, such that we can implement specific tests (state >> transitions, data exchange tests, etc.) during the hackfest which could in >> parallel guide our implementation efforts. >> >> Thanks, >> >> Sascha >> ______________________________**_________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers >> >> ______________________________**__ >> >> The material in this message is private and may contain Protected >> Healthcare Information (PHI). If you are not the intended recipient, be >> advised that any unauthorized use, disclosure, copying or the taking of any >> action in reliance on the contents of this information is strictly >> prohibited. If you have received this email in error, please immediately >> notify the sender via telephone or return mail. >> > > ______________________________**_________________ > 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: From antdass at gmail.com Tue Sep 13 08:46:16 2011 From: antdass at gmail.com (Anthony Dass) Date: Tue, 13 Sep 2011 04:46:16 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <4E69CDD0.4090807@dkfz-heidelberg.de> References: <4E69CDD0.4090807@dkfz-heidelberg.de> Message-ID: Hi Sascha, thank you very much for looking into this issue and helping us with your solutions. For your reference, below is the message traced from the default ctk example, between the CTK host and app. As Ben, suggested It looks there could be something wrong at the QtSoap level itself so I'll try to debug the Qtsoap library. In case if you have a different version that has the namespace appearing or if you have some suggestions please let us know. *IDLE Once again thank you very much! ~Anthony On Fri, Sep 9, 2011 at 4:26 AM, Sascha Zelzer wrote: > ** > Hi, > > > On 09/09/2011 01:18 AM, Anthony Dass wrote: > > 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. > > > I had a look at the messages yesterday and could actually not reproduce > your problem with the missing namespace (the messages between the CTK host > and CTK app looked correct). I also looked at the QtSoap code and could not > spot a problem at first sight. > > Best, > Sascha > > > > thank you very much! > /Anthony > > > On Thu, Sep 8, 2011 at 6:47 AM, 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 >> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched >> from Non-CTK Host >> To: Sascha Zelzer >> Cc: Anthony Dass , 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). >> > > 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 >> > > >> > > >> > > >> > > 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 >> > > >> > > 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 > > > 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). ... >> > 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: From maxime.sermesant at inria.fr Tue Sep 13 08:48:22 2011 From: maxime.sermesant at inria.fr (Maxime Sermesant) Date: Tue, 13 Sep 2011 10:48:22 +0200 (CEST) Subject: [Ctk-developers] A more general discussion on the CTK at MICCAI 2011? In-Reply-To: <4E6F063F.2070409@creatis.insa-lyon.fr> Message-ID: Hi all, I'll be there for Inria. Best wishes, -- Maxime ----- Original Message ----- > From: "Maciej ORKISZ" > To: "Frederic Cervenansky" > Cc: "Stephen Aylward" , "Maxime Sermesant" , > kikinis at bwh.harvard.edu, ctk-developers at commontk.org, "Gianluca US) Paladini (SCR" , > "Meinzer Hans-Peter" , "Ivo Wolf" > Sent: Tuesday, 13 September, 2011 9:29:03 AM > Subject: Re: Fwd: Re: [Ctk-developers] A more general discussion on the CTK at MICCAI 2011? > > Dear All, > Fr?d?ric informed me about the meeting planned. As I will attend the > conference, I am also willing to participate in the meeting on > behalf of CREATIS. > See you in Toronto > Maciej > > . > Le 13/09/2011 09:11, Frederic Cervenansky a ?crit : > > > Stephen Aylward > Pour : Maxime Sermesant , > kikinis at bwh.harvard.edu , ctk-developers at commontk.org , "Gianluca > US) Paladini (SCR" , Meinzer > Hans-Peter , Ivo Wolf > > -- > Maciej ORKISZ > > affiliation: > CREATIS; > Universit? de Lyon; > Universit? Lyon 1; > INSA-Lyon; > CNRS UMR 5220; > Inserm U1044; > > postal address: > CREATIS > Campus LyonTech la Doua - INSA de Lyon > b?t. Blaise Pascal > 7 rue Jean Capelle > F-69621 Villeurbanne Cedex > France > > Phone : +33 (0)4 72 43 74 35 > Fax : +33 (0)4 72 43 85 26 > e-mail : maciej.orkisz at creatis.insa-lyon.fr CREATIS home page : > http://www.creatis.insa-lyon.fr/ personal page : > https://www.creatis.insa-lyon.fr/site/fr/users/orkisz -- Maxime From antdass at gmail.com Wed Sep 14 01:24:39 2011 From: antdass at gmail.com (Anthony Dass) Date: Tue, 13 Sep 2011 21:24:39 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> Message-ID: 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 ========================= CANCELED Got Response. Response: - name space for type attribute is present. ========================= " false Thank you! /Anthony On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze 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, 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 >> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched >> from Non-CTK Host >> To: Sascha Zelzer >> Cc: Anthony Dass , 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). >> > > 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 >> > > >> > > >> > > >> > > 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 >> > > >> > > 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 > > > 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). ... >> > 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: From jchris.fillionr at kitware.com Wed Sep 14 20:14:59 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 14 Sep 2011 16:14:59 -0400 Subject: [Ctk-developers] Remarks about Applications/ctkDICOM/Testing/Cpp Message-ID: Folks, In most of the test associated with the ctkDICOM applications, I noticed that target_libraries.cmake is used. Few remarks: - Using the macro ctkFunctionGetTargetLibraries in CMakeLists.txt associated with tests hasn't been tested -- But I guess nothing prevent would prevent from using it - Even if possible, using this macro and the associated * target_libraries.cmake* file won't be useful. Indeed, the initial idea behind *target_libraries.cmake* is to know the dependency of library from the Superbuild level. The system doesn't handle the dependency associated with tests. (It could be extended to do so ...) - Since the file is *target_libraries.cmake *parsed using a regular expression, conditional definition won't work within the file. It means the following files should be fixed: - https://github.com/commontk/CTK/blob/master/Applications/ctkDICOM/Testing/Cpp/CMakeLists.txt - https://github.com/commontk/CTK/blob/master/Applications/ctkDICOM/Testing/Cpp/target_libraries.cmake - The same remarks applies for all tests associated with ctkDICOM applications What shout be done: - If testing a command line application: Invoke that application - If designing some unit testing for some widget of that application: - May be these widgets should belong to CTK libraries .. ? - If not, create a statit or shared librarie that both the application and the test could link against Any questions, let me know Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From antdass at gmail.com Sun Sep 18 13:21:19 2011 From: antdass at gmail.com (Anthony Dass) Date: Sun, 18 Sep 2011 09:21:19 -0400 Subject: [Ctk-developers] notifyStateChanged(INPROGRESS) seems to be getting submitted before SetStateResponse Message-ID: Hello Sacha and Ben, In addition to my previous issues on using the CTK based App with a Non-CTK based Host, I've also observed that the reply message is not getting respected by the ctk. for instance, when the host sends the setState(State.INPROGRESS) message to the ctk-App, the ctk-App on processing SetState, attempts to submit notifyStateChanged(State.INPROGRESS) to the host even before it replies to host with setStateResponse. where as the non-ctk based host continues to wait for the reply message setStateResponse and does't send the notifyDataAvailable to the app though the app had submitted the notifyStateChanged message to the Host. The notifyStateChanged message should be submitted after the reply of SetStateResponse right? could you please clarify on this. Thank you very much! /Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Mon Sep 19 11:59:59 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Mon, 19 Sep 2011 13:59:59 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> Message-ID: <4E772EBF.7040106@dkfz-heidelberg.de> 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 > ========================= > 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 "> > > > CANCELED > > > > > Got Response. Response: - name space for type attribute is present. > ========================= > " 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"> > > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xsi:type="xsd:boolean" > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false > > > > > Thank you! > /Anthony > > On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze > 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, > > 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 > > Subject: Re: [Ctk-developers] CTK based Hosted App fails > when launched > from Non-CTK Host > To: Sascha Zelzer > > Cc: Anthony Dass >, 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). > > > 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 > > > > > > > > > > > > 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 > > > 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 > > 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). ... > > 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: > > > ------------------------------ > > _______________________________________________ > 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: From benoit.bleuze at inria.fr Mon Sep 19 13:06:08 2011 From: benoit.bleuze at inria.fr (Benoit Bleuze) Date: Mon, 19 Sep 2011 15:06:08 +0200 (CEST) Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <4E772EBF.7040106@dkfz-heidelberg.de> Message-ID: <1116230078.216317.1316437568240.JavaMail.root@zmbs4.inria.fr> 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 > > ========================= > > > > > > > > CANCELED > > > > > > > > Got Response. Response: - name space for type attribute is present. > > ========================= > > " > ns:xsd=" http://www.w3.org/1999/XMLSchema "> > > > > > > > xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance > > ">false > > > > > > > > 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). > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > 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 > > > > > > 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). ... > > > > > > 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: From s.zelzer at dkfz-heidelberg.de Mon Sep 19 13:38:48 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Mon, 19 Sep 2011 15:38:48 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <1116230078.216317.1316437568240.JavaMail.root@zmbs4.inria.fr> References: <1116230078.216317.1316437568240.JavaMail.root@zmbs4.inria.fr> Message-ID: <4E7745E8.2070008@dkfz-heidelberg.de> 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 > ========================= > 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 "> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > > CANCELED > > > > > Got Response. Response: - name space for type attribute is > present. > ========================= > " 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"> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xsi:type="xsd:boolean" > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false > > > > > Thank you! > /Anthony > > On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze > > 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, > > 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 > > Subject: Re: [Ctk-developers] CTK based Hosted App > fails when launched > from Non-CTK Host > To: Sascha Zelzer > > Cc: Anthony Dass >, > 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). > > > 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 > > > > > > > > > > > > > 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 > > > > > > > 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 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). ... > > 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: > > > ------------------------------ > > _______________________________________________ > 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: From antdass at gmail.com Mon Sep 19 14:18:15 2011 From: antdass at gmail.com (Anthony Dass) Date: Mon, 19 Sep 2011 10:18:15 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <4E772EBF.7040106@dkfz-heidelberg.de> References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> Message-ID: 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 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 > ========================= > > > > CANCELED > > > > > Got Response. Response: - name space for type attribute is present. > ========================= > " ns:xsd="http://www.w3.org/1999/XMLSchema"> > > > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance > ">false > > > > > Thank you! > /Anthony > > On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze 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, 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 >>> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched >>> from Non-CTK Host >>> To: Sascha Zelzer >>> Cc: Anthony Dass , 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). >>> > > 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 >>> > > >>> > > >>> > > >>> > > 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 >>> > > >>> > > 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 >> > > 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). ... >>> > 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: From s.zelzer at dkfz-heidelberg.de Mon Sep 19 14:31:01 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Mon, 19 Sep 2011 16:31:01 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> Message-ID: <4E775225.70304@dkfz-heidelberg.de> 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 > > 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 >> ========================= >> > 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 "> >> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >> >> CANCELED >> >> >> >> >> Got Response. Response: - name space for type attribute is present. >> ========================= >> "> 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"> >> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >> xsi:type="xsd:boolean" >> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false >> >> >> >> >> Thank you! >> /Anthony >> >> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze >> > 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, >> > > 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 > > >> Subject: Re: [Ctk-developers] CTK based Hosted App >> fails when launched >> from Non-CTK Host >> To: Sascha Zelzer > > >> Cc: Anthony Dass > >, >> 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). >> > > 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 > >> > > >> > > >> > > >> > > 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 >> > > > 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 > 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). ... >> > 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: >> >> >> ------------------------------ >> >> _______________________________________________ >> 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: From jchris.fillionr at kitware.com Mon Sep 19 15:19:15 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 19 Sep 2011 11:19:15 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <4E775225.70304@dkfz-heidelberg.de> References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> <4E775225.70304@dkfz-heidelberg.de> Message-ID: Good catch ! For proper implementation of Singleton, you could refer to ctkSingleton.h See https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h Thanks Jc On Mon, Sep 19, 2011 at 10:31 AM, Sascha Zelzer wrote: > 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> 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 >> ========================= >> >> >> >> CANCELED >> >> >> >> >> Got Response. Response: - name space for type attribute is present. >> ========================= >> "> ns:xsd="http://www.w3.org/1999/XMLSchema"> >> >> >> > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance >> ">false >> >> >> >> >> Thank you! >> /Anthony >> >> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze 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, 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 >>>> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched >>>> from Non-CTK Host >>>> To: Sascha Zelzer >>>> Cc: Anthony Dass , 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). >>>> > > 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 >>>> > > >>>> > > >>>> > > >>>> > > 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 >>>> > > >>>> > > 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 >>> > > 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). ... >>>> > 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 >>>> ********************************************* >>>> >>> >>> >>> >> >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Mon Sep 19 16:19:11 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Mon, 19 Sep 2011 18:19:11 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> <4E775225.70304@dkfz-heidelberg.de> Message-ID: <4E776B7F.2040800@dkfz-heidelberg.de> Hi Jc, 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. Thanks, Sascha On 09/19/2011 05:19 PM, Jean-Christophe Fillion-Robin wrote: > Good catch ! > > For proper implementation of Singleton, you could refer to ctkSingleton.h > > See https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h > > Thanks > Jc > > On Mon, Sep 19, 2011 at 10:31 AM, Sascha Zelzer > > wrote: > > 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 >> > > 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 >>> ========================= >>> >> 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 >>> "> >>> >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>> >>> CANCELED >>> >>> >>> >>> >>> Got Response. Response: - name space for type attribute is >>> present. >>> ========================= >>> ">> 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"> >>> >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>> >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>> >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >>> xsi:type="xsd:boolean" >>> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false >>> >>> >>> >>> >>> Thank you! >>> /Anthony >>> >>> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze >>> > 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, >>> >> > 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 >> > >>> Subject: Re: [Ctk-developers] CTK based Hosted >>> App fails when launched >>> from Non-CTK Host >>> To: Sascha Zelzer >> > >>> Cc: Anthony Dass >> >, >>> 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). >>> > > 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 > >>> > > >>> > > >>> > > >>> > > 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 >>> > > >> > >>> > > 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 >> 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). ... >>> > 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: >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 >>> ********************************************* >>> >>> >>> >>> >> >> > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Sep 19 16:25:07 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 19 Sep 2011 12:25:07 -0400 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: <4E776B7F.2040800@dkfz-heidelberg.de> References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> <4E775225.70304@dkfz-heidelberg.de> <4E776B7F.2040800@dkfz-heidelberg.de> Message-ID: 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. See https://secure.wikimedia.org/wikibooks/en/wiki/More_C%2B%2B_Idioms/Nifty_Counter Jc On Mon, Sep 19, 2011 at 12:19 PM, Sascha Zelzer wrote: > Hi Jc, > > 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. > > Thanks, > Sascha > > > On 09/19/2011 05:19 PM, Jean-Christophe Fillion-Robin wrote: > > Good catch ! > > For proper implementation of Singleton, you could refer to ctkSingleton.h > > See https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h > > Thanks > Jc > > On Mon, Sep 19, 2011 at 10:31 AM, Sascha Zelzer < > s.zelzer at dkfz-heidelberg.de> wrote: > >> 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> 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 >>> ========================= >>> >>> >>> >>> CANCELED >>> >>> >>> >>> >>> Got Response. Response: - name space for type attribute is present. >>> ========================= >>> ">> ns:xsd="http://www.w3.org/1999/XMLSchema"> >>> >>> >>> >> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance >>> ">false >>> >>> >>> >>> >>> Thank you! >>> /Anthony >>> >>> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze 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, 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 >>>>> Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched >>>>> from Non-CTK Host >>>>> To: Sascha Zelzer >>>>> Cc: Anthony Dass , 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). >>>>> > > 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 >>>>> > > >>>>> > > >>>>> > > >>>>> > > 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 >>>>> > > >>>>> > > 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 >>>> > > 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). ... >>>>> > 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 >>>>> ********************************************* >>>>> >>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- > +1 919 869 8849 > > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Mon Sep 19 16:35:46 2011 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Mon, 19 Sep 2011 18:35:46 +0200 Subject: [Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6 In-Reply-To: References: <909447054.76791.1315557078096.JavaMail.root@zmbs4.inria.fr> <4E772EBF.7040106@dkfz-heidelberg.de> <4E775225.70304@dkfz-heidelberg.de> <4E776B7F.2040800@dkfz-heidelberg.de> Message-ID: <4E776F62.6010402@dkfz-heidelberg.de> I can see how it helps to initialize static data for a singleton consistently for multiple compilation units within one library. However, I do not understand how the duplication of the "nifty_counter" symbol in Stream.cpp (if compiled into a static lib) could be prevented when it is linked from multiple dlls? - Sascha On 09/19/2011 06:25 PM, Jean-Christophe Fillion-Robin wrote: > 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. > > See > https://secure.wikimedia.org/wikibooks/en/wiki/More_C%2B%2B_Idioms/Nifty_Counter > > Jc > > On Mon, Sep 19, 2011 at 12:19 PM, Sascha Zelzer > > wrote: > > Hi Jc, > > 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. > > Thanks, > Sascha > > > On 09/19/2011 05:19 PM, Jean-Christophe Fillion-Robin wrote: >> Good catch ! >> >> For proper implementation of Singleton, you could refer to >> ctkSingleton.h >> >> See >> https://github.com/commontk/CTK/blob/master/Libs/Core/ctkSingleton.h >> >> Thanks >> Jc >> >> On Mon, Sep 19, 2011 at 10:31 AM, Sascha Zelzer >> > > wrote: >> >> 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 >>> >> > 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 >>>> ========================= >>>> >>> 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 >>>> "> >>>> >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>>> >>>> CANCELED >>>> >>>> >>>> >>>> >>>> Got Response. Response: - name space for type >>>> attribute is present. >>>> ========================= >>>> ">>> 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"> >>>> >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>>> >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>>> >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >>>> xsi:type="xsd:boolean" >>>> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">false >>>> >>>> >>>> >>>> >>>> Thank you! >>>> /Anthony >>>> >>>> On Fri, Sep 9, 2011 at 4:31 AM, Benoit Bleuze >>>> >>> > 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, >>>> >>> > >>>> 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 >>> > >>>> Subject: Re: [Ctk-developers] CTK based >>>> Hosted App fails when launched >>>> from Non-CTK Host >>>> To: Sascha Zelzer >>>> >>> > >>>> Cc: Anthony Dass >>> >, >>>> 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 >>>> > > >>>> > > >>>> > > >>>> > > 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 >>>> > > >>> s:Body > >>>> > > 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 >>> 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). ... >>>> > 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: >>>> >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>>> ********************************************* >>>> >>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> >> >> >> -- >> +1 919 869 8849 >> > > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Sep 20 21:48:23 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 20 Sep 2011 17:48:23 -0400 Subject: [Ctk-developers] Property manager / mechanism Message-ID: Hi Folks, Working on a new project, I will have to implement a property manager. 1) Before coming up with a custom solution, I was wondering what kind of system you were using in your respective application? 2) The system I envision would have the following characteristics: - Easily extensible to support new type of object - Simple - Serialization of property (Json?, Xml ?) - Support undo / redo 3) What would you do differently in your current implementation(s) ? Thanks for you help Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Wed Sep 21 19:44:45 2011 From: julien.finet at kitware.com (Julien Finet) Date: Wed, 21 Sep 2011 15:44:45 -0400 Subject: [Ctk-developers] Give your cute (Qt) GUI some pop In-Reply-To: <20110921193216.CB5D4282CF0@www.kitware.com> References: <20110921193216.CB5D4282CF0@www.kitware.com> Message-ID: A new article has just been posted on the The Kitware Blog at http://www.kitware.com/blog/home/post/169 *Give your cute (Qt) GUI some pop* by *Julien Finet* (Open Source) *Your app is too cluttered, use ctkPopupWidget* Close your eyes... take a long breath in... and breathe out... clear up your mind... and think about your favorite application (it should be the one you are working on :-P ). Keep your eyes closed and visualize all the graphical elements of the application: buttons, frames, panels, texts, scroll-bars, menus... how many do you count ? That's a lot to think about, isn't it? If you have scroll-bars, it probably means that there is not enough space to show all the widgets at once, and that you need extra space. Now, put yourself in the shoes of someone who plays with your application for the first time... don't you feel overwhelmed by the amount of visual information? Where to click ? What buttons are important ? Which ones are not ? I'll skip the pamphlet explaining why it's a bad idea to have a heavy UI. You can open your eyes now and let me present you another way of showing useful widgets at the right time and hiding them when not needed: * ctkPopupWidget * [image: Slice view popup] Popup to control a 2D view As a result we managed to cleanup the UI of the Slicer main window: Slicer3 with slice view controllers visible Slicer4 with slice view controllers as popups As its name indicates, ctkPopupWidget is: - part of CTK (Apache 2 license), used in 3D Slicer - a popup: with full control over where and how to popup - a widget: respects all the properties of a Qt widget (e.g. parent/child relationship, background transparency) [image: Example of a semi transparent popup] Popup to control the range of a slider ctkPopupWidget is easy to use, let's look at a line by line example: QSpinBox* spinBox = new QSpinBox(parentWidget); // the spinbox is the parent of the popup, ctkPopupWidget* popup = new ctkPopupWidget(spinBox); // the popup is placed relative to the spinbox QHBoxLayout* popupLayout = new QHBoxLayout(popup); // populate the popup with a vertical QSlider: QSlider* popupSlider = new QSlider(Qt::Vertical, popup); // add here the signal/slot connection between the slider and the spinbox popupLayout->addWidget(popupSlider); // Control where to display the the popup relative to the parent popupSlider->setAlignment(Qt::Left | Qt::Top); // at the top left corner popupSlider->setHorizontalDirection( Qt::RightToLeft ); // open outside the parent popupSlider->setVerticalDirection(ctkBasePopupWidget::TopToBottom); // at the left of the spinbox sharing the top border // Control the animation popupSlider->setAnimationEffect(ctkBasePopupWidget::ScrollEffect); // could also be FadeEffect popupSlider->setOrientation(Qt::Horizontal); // how to animate, could be Qt::Vertical or Qt::Horizontal|Qt::Vertical popupSlider->setEasingCurve(QEasingCurve::OutQuart); // how to accelerate the animation, QEasingCurve::Type popupSlider->setEffectDuration(100); // how long in ms. // Control the behavior popupSlider->setAutoShow(true); // automatically open when the mouse is over the spinbox popupSlider->setAutoHide(true); // automatically hide when the mouse leaves the popup or the spinbox. See below the result of the previous code, the slider popup opens on the left of the spinbox. Another example of use for a popup slider: as a view item delegate Popup in a custom QItemDelegate Most of these properties have a good default value and don't need to be manually set. Here is the complete API for ctkPopupWidget. See below more popup tuning: Background fade effect Elastic easing curve Note that you can also design the popup UI using Qt Designer. All you then need to do is: QSpinBox* spinBox = new QSpinBox(parentWidget); ctkPopupWidget* popup = new ctkPopupWidget(spinBox); Ui_myPopup::setupUi(popup); // sets the child widgets and the popup properties. A popup widget follows its parent when moved, hides if the parent is hidden or disabled. Popups can be nested, pinned, unpinned, flattened (dynamically change from a popup mode into a regular widget). [image: pin/unpin example] Pin and Unpin There are still a few corner cases that can be improved, the fade effect is still a bit experimental and there are a few issues with dialogs or windows moved over the popup. Nonetheless, we started to add a "popup mode" to some widgets in CTK, e.g. ctkSliderWidget::setPopupSlider(bool). As a side note, you can also consider ctkCollapsibleButtonand ctkCollapsibleGroupBoxas other alternatives to conveniently "show"/"hide" widgets. Any question? let me know. Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.wolf at vision.ee.ethz.ch Thu Sep 29 16:25:20 2011 From: thomas.wolf at vision.ee.ethz.ch (Thomas Wolf) Date: Thu, 29 Sep 2011 18:25:20 +0200 Subject: [Ctk-developers] unknown log4qt in non-superbuild In-Reply-To: References: Message-ID: <4E849BF0.8060308@vision.ee.ethz.ch> Hello all, i have some problems with the non superbuild. I have a makefile similar along those lines: add_subdirectory(Log4Qt) add_subdirectory(GDCM) and finally add_subdirectory(CTK) Ibuild my externals directly in my makefile. External_project does not work here because another parent project cannot be allowed to be a external_project. Running through configuration step, i get the following: <--- EXTERNAL_TARGETS: CMake Error at 3rdParty/CTK/CMake/ctkMacroValidateBuildOptions.cmake:202 (MESSAGE): CTKCore depends on unknown external targets: Log4Qt_LIBRARIES Call Stack (most recent call first): 3rdParty/CTK/CMakeLists.txt:512 (ctkMacroValidateBuildOptions) ---> similar also for GDCM. if i remove in the CTK main makefiles (ll. 507) the block with #----------------------------------------------------------------------------- # Let's make sure the enabled/disabled libraries, plugins or applications are coherent # ctkFunctionGenerateDGraphInput(${CTK_BINARY_DIR} "${target_directories}") ctkFunctionGenerateDGraphInput(${CTK_BINARY_DIR} "${target_directories}" WITH_EXTERNALS) ctkMacroValidateBuildOptions("${CTK_BINARY_DIR}" "${DGraph_EXECUTABLE}" "${target_directories}") it works somehow, at leats throug makefile generation. is the DGraph executable expecting a 'hard' target, as export? isn't the Log4Qt target already visible? There's no problem configuring and building it in the same makefile, just by disabling CTK.. Regards, Thomas From thomas.wolf at vision.ee.ethz.ch Thu Sep 29 16:27:17 2011 From: thomas.wolf at vision.ee.ethz.ch (Thomas Wolf) Date: Thu, 29 Sep 2011 18:27:17 +0200 Subject: [Ctk-developers] Obligatory external libraries target in ctk non-superbuild Message-ID: <4E849C65.8010109@vision.ee.ethz.ch> Hello all, I have a problem with the non-superbuild mode of the CTK build. I have Visual Stuido 2008 under windows 7 x64, and due to project restrictions (no git, integrated and contained build, no downloads) I do not use the superbuild. I have all needed subprojects also in my build, which build fine and flawless. The problem is, CTK expects a hardcoded target called Log4Qt_LIBRARIES in ctkMacroValidateBuildOptions.cmake line 192. Why is this? The Log4Qt downloaded by CTK (experimental superbuild :) ) doesnt define this target, so it must be something that comes via the superbuild of CTK. I can imagine that the Log4Qt_LIBRARIES is the one defined by find_package, but that is a variable and not a target, right? Is there a solution to this? Or should i create a custom target"Log4Qt_LIBRARIES" for the non-superbuild? Regards, Thomas From jchris.fillionr at kitware.com Thu Sep 29 18:29:35 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 29 Sep 2011 14:29:35 -0400 Subject: [Ctk-developers] unknown log4qt in non-superbuild In-Reply-To: <4E849BF0.8060308@vision.ee.ethz.ch> References: <4E849BF0.8060308@vision.ee.ethz.ch> Message-ID: Hi Thomas, Please consider the following use case and associated comments: #-------------------- # Build Log4Qt standalone git clone git://github.com/commontk/Log4Qt.git mkdir Log4Qt-build cd Log4Qt-build cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Projects/qtsdk-2010.05/qt/bin/qmake ../Log4Qt && make -j4 #-------------------- #-------------------- # Checkout CTK source git clone git://github.com/commontk/CTK.git CTK #-------------------- #-------------------- # Use case1: Build CTK with CTK_SUPERBUILD OFF specifying Log4Qt_DIR mkdir CTK-UseCase1-build cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Projects/qtsdk-2010.05/qt/bin/qmake -DCTK_SUPERBUILD:BOOL=OFF -DCTK_LIB_PluginFramework:BOOL=OFF -DLog4Qt_DIR:PATH=/home/jchris/Projects/sandbox/Log4Qt-build/ -DBUILD_TESTING:BOOL=OFF ../CTK => CMake Error at Libs/Core/CMakeLists.txt:6 (INCLUDE): include called with wrong number of arguments. Include only takes one file. #-------------------- #-------------------- # Use case2: Build CTK with CTK_SUPERBUILD ON specifying Log4Qt_DIR mkdir CTK-UseCase2-build cmake -DQT_QMAKE_EXECUTABLE:FILEPATH=/home/jchris/Projects/qtsdk-2010.05/qt/bin/qmake -DCTK_LIB_PluginFramework:BOOL=OFF -DLog4Qt_DIR:PATH=/home/jchris/Projects/sandbox/Log4Qt-build/ -DBUILD_TESTING:BOOL=OFF ../CTK => It works #-------------------- Obviously, UseCase1 couldn't be completed. It means, CTK can't be added as a regular project with CTK_SUPERBUILD:OFF I could look at the issue next week ... before doing so. Seems we need to find way to generalize the code in Superbuild.cmake - line 135 to line 156 Sasha> Any suggestions ? Waiting we find a solution, would it be possible for you to follow what's done in UseCase2 to have your project compiling and linking. You could do something like: Within the /path/to/ThirdParty/CMakeLists.txt SET(CTK_LIB_PluginFramework OFF) SET(CTK_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}) SET(CTK_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}) SET(CTK_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}) SET(LogQt_DIR "/path/to/Log4Qt-build") add_subdirectory(CTK) set(CTK_DIR ${CMAKE_CURRENT_BINARY_DIR}/CTK-build) find_package(CTK) Thanks Jc On Thu, Sep 29, 2011 at 12:25 PM, Thomas Wolf wrote: > Hello all, > > i have some problems with the non superbuild. > I have a makefile similar along those lines: > > add_subdirectory(Log4Qt) > add_subdirectory(GDCM) > > and finally > add_subdirectory(CTK) > > Ibuild my externals directly in my makefile. External_project does not > work here because another parent project cannot be allowed to be a > external_project. > > Running through configuration step, i get the following: > > <--- > EXTERNAL_TARGETS: > CMake Error at 3rdParty/CTK/CMake/ctkMacroValidateBuildOptions.cmake:202 > (MESSAGE): > CTKCore depends on unknown external targets: Log4Qt_LIBRARIES > Call Stack (most recent call first): > 3rdParty/CTK/CMakeLists.txt:512 (ctkMacroValidateBuildOptions) > ---> > > similar also for GDCM. > > if i remove in the CTK main makefiles (ll. 507) the block with > > > #----------------------------------------------------------------------------- > # Let's make sure the enabled/disabled libraries, plugins or > applications are coherent > # > ctkFunctionGenerateDGraphInput(${CTK_BINARY_DIR} "${target_directories}") > ctkFunctionGenerateDGraphInput(${CTK_BINARY_DIR} "${target_directories}" > WITH_EXTERNALS) > ctkMacroValidateBuildOptions("${CTK_BINARY_DIR}" "${DGraph_EXECUTABLE}" > "${target_directories}") > > it works somehow, at leats throug makefile generation. > > is the DGraph executable expecting a 'hard' target, as export? > > isn't the Log4Qt target already visible? There's no problem configuring > and building it in the same makefile, just by disabling CTK.. > > Regards, > Thomas > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Sep 29 18:34:06 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 29 Sep 2011 14:34:06 -0400 Subject: [Ctk-developers] Obligatory external libraries target in ctk non-superbuild In-Reply-To: <4E849C65.8010109@vision.ee.ethz.ch> References: <4E849C65.8010109@vision.ee.ethz.ch> Message-ID: Hi Thomas, Please, consider reading the following document: http://www.commontk.org/index.php/Documentation/BuildSystem_Description As mentionned in reply to your previous question, use case where CTK_SUPERBUILD:OFF isn't supported. See http://public.kitware.com/pipermail/ctk-developers/2011-September/000841.htmlto see how you could implement an alternative solution. Thanks Jc On Thu, Sep 29, 2011 at 12:27 PM, Thomas Wolf wrote: > Hello all, > > I have a problem with the non-superbuild mode of the CTK build. I have > Visual Stuido 2008 under windows 7 x64, and due to project restrictions > (no git, integrated and contained build, no downloads) I do not use the > superbuild. I have all needed subprojects also in my build, which build > fine and flawless. > > The problem is, CTK expects a hardcoded target called Log4Qt_LIBRARIES > in ctkMacroValidateBuildOptions.cmake line 192. > > Why is this? The Log4Qt downloaded by CTK (experimental superbuild :) ) > doesnt define this target, so it must be something that comes via the > superbuild of CTK. I can imagine that the Log4Qt_LIBRARIES is the one > defined by find_package, but that is a variable and not a target, right? > > Is there a solution to this? > > Or should i create a custom target"Log4Qt_LIBRARIES" for the > non-superbuild? > > Regards, > Thomas > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.wolf at vision.ee.ethz.ch Fri Sep 30 10:22:20 2011 From: thomas.wolf at vision.ee.ethz.ch (Thomas Wolf) Date: Fri, 30 Sep 2011 12:22:20 +0200 Subject: [Ctk-developers] unknown log4qt in non-superbuild In-Reply-To: References: <4E849BF0.8060308@vision.ee.ethz.ch> Message-ID: <4E85985C.2090307@vision.ee.ethz.ch> Hi Jean-Christophe, thansk for inspecting the matter. I am currently investigating your suggestion. > > Waiting we find a solution, would it be possible for you to follow > what's done in UseCase2 to have your project compiling and linking. > > You could do something like: > Within the /path/to/ThirdParty/CMakeLists.txt > > SET(CTK_LIB_PluginFramework OFF) > SET(CTK_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}) > SET(CTK_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}) > SET(CTK_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}) > SET(LogQt_DIR "/path/to/Log4Qt-build") > add_subdirectory(CTK) > set(CTK_DIR ${CMAKE_CURRENT_BINARY_DIR}/CTK-build) > find_package(CTK) I'm slightly puzzled. Why do you turn of the CTKPluginFramework? As my parent project is MITK, CTKPluginFramework ist actually *the thing* i need from CTK. Regards, Thomas From jchris.fillionr at kitware.com Fri Sep 30 16:00:03 2011 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 30 Sep 2011 12:00:03 -0400 Subject: [Ctk-developers] unknown log4qt in non-superbuild In-Reply-To: <4E85985C.2090307@vision.ee.ethz.ch> References: <4E849BF0.8060308@vision.ee.ethz.ch> <4E85985C.2090307@vision.ee.ethz.ch> Message-ID: On Fri, Sep 30, 2011 at 6:22 AM, Thomas Wolf wrote: > Hi Jean-Christophe, > > thansk for inspecting the matter. I am currently investigating your > suggestion. > > > > > Waiting we find a solution, would it be possible for you to follow > > what's done in UseCase2 to have your project compiling and linking. > > > > You could do something like: > > Within the /path/to/ThirdParty/CMakeLists.txt > > > > SET(CTK_LIB_PluginFramework OFF) > > SET(CTK_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}) > > SET(CTK_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}) > > SET(CTK_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}) > > SET(LogQt_DIR "/path/to/Log4Qt-build") > > add_subdirectory(CTK) > > set(CTK_DIR ${CMAKE_CURRENT_BINARY_DIR}/CTK-build) > > find_package(CTK) > > > I'm slightly puzzled. Why do you turn of the CTKPluginFramework? As my > parent project is MITK, CTKPluginFramework ist actually *the thing* i > need from CTK. > This was just an example ... I wanted to test quickly and I enabled the minimum. Jc > > Regards, > Thomas > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: