2019 up to now | 2018 2017  |  2016  | 2015 | 2014 | 2013 | 2012

Mailing List - Entries of 2012

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QF-Test] Remote connection to a SUT

  • Subject: [QF-Test] Remote connection to a SUT
  • From: "Gauthier, Denis" <Denis.Gauthier@?.au>
  • Date: Fri, 17 Feb 2012 14:49:39 +1100

Dear QFTest Support group,

I was just wondering what are the technical reasons that require QFTest to start the SUT.
In the past when the JVM had to be instrumented, I can quite understand. But now that this is gone, what is preventing QFTest from connecting to a running application like a debugger would do?
Is there something that can be done on the SUT side to help (like adding a few jars to the classpath)?

I am asking because most applications I am integrating QFTest with are started by a supervision and actively monitored.
Begin able to tweak the supervision to start QFTest who in turn starts the SUT is often the biggest upfront challenge.

Is there a real constraint here or is this just that there was not enough requests for this improvement?

Thank you,


------------------------------------------------------------------------- DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -------------------------------------------------------------------------