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

Mailing List - Entries from 2018 up to now

<html>
  <head>
    
  </head>
  <body bgcolor="#FFFFFF" text="#000099">
    Hi Martin,<br>
    <br>
    sorry I could not try this before, but this is gold!<br>
    <br>
    One extra thing is to add to our SUT java command line:<br>
    <i>    -Xbootclasspath/<a class="moz-txt-link-freetext" href="p:$">p:$</a>{QFTEST_VERSIONDIR}/misc/qfconnect.jar
-Djavax.accessibility.assistive_technologies=de.qfs.apps.qftest.start.Connector</i><br>
    <br>
    and it works a treat!<br>
    No need to start any dummy client within QFTest (at least with
    3.4.4).<br>
    <br>
    This tremendously simplifies the integration of QFTest within
    complex environments.<br>
    <br>
    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).<br>
    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....<br>
    <br>
    Thanks heaps,<br>
    <div class="moz-signature">
      <p style="font-family:arial;font-size:12px;color:#808080;"><b
          style="color:#0000FF;">Denis GAUTHIER</b><br>
      </p>
    </div>
    <br>
    On 17/02/2012 6:51 PM, Martin Moser wrote:
    <blockquote cite="mid:6DA3E67509EA41E92E7BC78C@martinl.qfs.de"
      type="cite">
      <pre wrap="">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" 
<a class="moz-txt-link-rfc2396E" href="mailto:Denis.Gauthier@thalesgroup.com.au"><Denis.Gauthier@thalesgroup.com.au></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">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.

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

</pre>
      </blockquote>
      <pre wrap="">


</pre>
    </blockquote>
  
-------------------------------------------------------------------------
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.  

-------------------------------------------------------------------------
</body>
</html>