Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Under macOS, Vergil.app does not set environment variables needed for hlacerti demos #329

Open
cxbrooks opened this issue Jun 20, 2018 · 1 comment

Comments

@cxbrooks
Copy link
Member

Note that some demos, such as the hlacerti demos, require certain environment variables to be set. If, under Mac OS, Vergil is invoked by clicking on Vergil.app, then these environment variables will not be set. The workaround is to invoke Vergil using $PTII/bin/vergil.

To fix this, the hlacerti manager should have attributes that are used to find the certi installation and then set the environment of any subprocesses that are created.

@cxbrooks
Copy link
Member Author

Below are some notes about this issue:

I'm guessing that the CERTI_FOM_PATH environment variable is read by the rtig subprocess, which is why it needs to be set, right?

$PTII/org/hlacerti/lib/CertiRtig.java is where rtig gets invoked. CertiRtig.java attempts to read CERTI_FOM_PATH


         // FIXMEjc: check ISAE tickets for writting the comments.
        String certiFomPath = "";
        if (System.getenv("CERTI_FOM_PATH") != null) {
             String certiFomPathVariable = System.getenv("CERTI_FOM_PATH");
             certiFomPath = "CERTI_FOM_PATH=" + certiFomPathVariable;
        } else {
             certiFomPath = "CERTI_FOM_PATH=" + certiHome + "/share/federations/";
        }
        _environmentArray[1] = certiFomPath;

         _directoryAsFile = new File(fedFileName.getParent());
         if (!_directoryAsFile.isDirectory()) {
             throw new IllegalActionException(_hlaManager,
                     "CertiRtig: initialize(): No such directory: "
                             + _directoryAsFile);
         }

Later _environmentArray is passed to java.lang.Runtime exec(), which is how the rtig subprocess environment sees the updated value of CERT_FOM_PATH environment variable.

Offhand, it looks like setting an environment variable in Java is not easy, see https://docs.oracle.com/javase/tutorial/essential/environment/env.html Basically, it looks like the only way to set an environment variable is to use it when a subprocess is created.

I think the place to set the variable is in the environment that is executing the JUnit test. For example if you are using Ant, then $PTII/build.xml.in would be modified so that when $PTII/configure is run, $PTII/build.xml.in is read in and $PTII/build.xml is created.

If the JUnit tests are invoked elsewhere, say from within Eclipse or Travis, then setting the CERT_FOM_PATH variable for those environments would be the best way.

A workaround would be to create a ptolemy/util/test/junit/AutoHlaCertiTests.java that extends ptolemy/util/test/junit/AutoTests.java but has a BeforeClass() method (see http://junit.sourceforge.net/javadoc/org/junit/BeforeClass.html) that sets a ptII.certi_fom_path property.

System.setProperty("ptII.certi_fom_path")="org/hlacerti/test/auto/FEDfiles"

The ptII.certi_fom_path property would then be read in org/hlacerti/lib/CertiRtig.java and be used to set the CERTI_FOM_PATH environment variable if CERTI_FOM_PATH is not set, or CertiRtig.java could always override CERTI_FOM_PATH if the ptII.certi_fom_path property is set.

I suggest using ptolemy.util.StringUtilities.getProperty("ptII.certi_fom_path") instead of calling System.getProperty("ptII.certi_fom_path") directly.

A ptolemy/util/test/junit/JUnitHlaCertiTest.java class would need to be created that is similar to ptolemy/util/test/junit/JUnitTclTestBase.java but invokes AutoHlaCertiTests instead of AutoTests.

Then org/hlacerti/test/junit/JUnitTclTest.java would be updated to extend ptolemy/util/test/junit/JUnitHlaCertiTests.java

In theory, org/hlaceri/test/junit/JUnitTclTest.java should be renamed to JUnitHlaCertiTest.java, but build.xml invokes /org/hlacerti//test/junit/JUnitTclTest.java so keeping the name as JUnitTclTest.java seems safer than renaming.

If the above is implemented, then it would work for running the org/hlacerti/test/junit/ JUnit tests from Travis or Eclipse without modifying the Travis or Eclipse environments or the environments that invoke Travis or Eclipse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant