2017 up to now  | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | 2009 | 2008 | 2007

(older archive entries before 2007 are not shown here, but included in the onsite-search)

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: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Thu, 10 May 2012 13:50:47 +0200

Hi Denis,

if you manage to set the System property

qftest.connector.suppress

to any non-null value before the AWT Toolkit gets initialized, the SUT
will not attempt to connect to QF-Test and should start up normally.

Best regards,
    Greg

"Gauthier, Denis" <Denis.Gauthier@?.au> writes:

> 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.
> -------------------------------------------------------------------------
>
> _______________________________________________
> qftest-list mailing list
> qftest-list@?.de
> http://www.qfs.de/mailman/listinfo/qftest-list

-- 
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                               Tel: +49 8171 38648-0
DE-82538 Geretsried                         Fax: +49 8171 3864816
GF: Gregor Schmid, Karlheinz Kellerer          HRB München 140833