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

Mailing List - Entries of 2012


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

Re: [QF-Test] Remote connection to a SUT


  • Subject: Re: [QF-Test] Remote connection to a SUT
  • From: "Gauthier, Denis" <Denis.Gauthier@?.au>
  • Date: Wed, 9 May 2012 11:27:29 +1000

Hi Martin,

sorry I could not try this before, but this is gold!

One extra thing is to add to our SUT java command line:
    -Xbootclasspath/p:${QFTEST_VERSIONDIR}/misc/qfconnect.jar -Djavax.accessibility.assistive_technologies=de.qfs.apps.qftest.start.Connector

and it works a treat!
No need to start any dummy client within QFTest (at least with 3.4.4).

This tremendously simplifies the integration of QFTest within complex environments.

One last question though, there is indeed a constraint that QFTest needs to be started first or the SUT will fail to start ( java.net.ConnectException: Connection refused).
Is there a way to disable the connector through environment variable? I could have in my SUT a variable to use or not QFTest without mocking around the java command line....

Thanks heaps,

Denis GAUTHIER


On 17/02/2012 6:51 PM, Martin Moser wrote:
Hi Denis,

if QF-Test connects to an application QF-Test still instruments the JRE, 
but this is happening via environment variables instead of copying files 
around now.

The environment variables tell the SUT's JRE to load the QF-Test connector 
classes for the SUT additionally.

The connector requires some dedicated QF-Test variables to be able to 
connect to your SUT. If you set those variables before the actual launch of 
your SUT manually, you could also connect to any running Java application.

Those environment variables look like this:

QFTEST_HOME=/opt/qftest (or your installation folder)
QFTEST_VERSIONDIR=/opt/qftest/qftest-3.4.4 (or your version folder)
QFTEST_SERVERNAME=qftest
QFTEST_CLIENTNAME=client
QFTEST_CLIENTID=0
QFTEST_SERVERHOST=localhost:3543


Constraints:
1.) You need to launch QF-Test before your SUT.
2.) In older versions you need to launch a dummy client in QF-Test first (I 
think not required for 3.4.4 anymore).

Best Regards,
Martin

--On Freitag, Februar 17, 2012 14:49:39 +1100 "Gauthier, Denis" 
<Denis.Gauthier@?.au> wrote:

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,
--

Denis GAUTHIER


-------------------------------------------------------------------------
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.

-------------------------------------------------------------------------



------------------------------------------------------------------------- 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. -------------------------------------------------------------------------