Wondering if it's possible to move the module directory in a JBoss 7 install to a non-default loco.
Does anyone know of a config param to specify where to pick it up?
Kinda like a conf-dir, bin-dir type of thing.
Thanks,
Aaron.
Yes, it's actually possible. As the documentation states, from within the standard launch scripts users are able to manipulate the module path by setting the $JBOSS_MODULEPATH environment variable. (If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules). The module path is provided to the running process via the -mp command line argument that is set in the standard scripts.
Related
I am begining to work with ORIENTDB and I have the following question.
Is it mandatory to set both environment variables? I was hoping to work with the studio without them, just setting the XML with my own environment variables.
Is there anyway to use custom variables programatically in my Java program?
Regards.
You don't need to set environment variables to work with OrientDB unless you're planning to run it from outside of its /bin directory, such as a service.
OrientDB Docs | Windows Service
OrientDB Docs | Unix Service
I finally understood what is missing.
When the "OServerPluginManager" is at startup, it uses the ORIENTDB_HOME setted + "plugins" to check the directory and register the plugins.
But between setting the plugin directory using the environment variable and registering the plugins, there is a overriding of properties checking the Server Property "plugin.directory".
So adding the property at server level with the directory where the plugins are will fix the problem.
I am using apache-spark 1.2.0 and would like my user's Linux environment variable $MY_KEY to be made available to my Java job when executed using master=local
In Java land this could be passed in using a -D parameter, but I cannot get this recognized when my driver is launched using spark-submit
I have tried adding this to conf/spark-defaults.conf, but spark will not resolve the environment variable $MY_KEY when it executes my Java job (I see this in my logs)
spark.driver.extraJavaOptions -Dkeyfile="${MY_KEY}"
I have tried adding the same as an argument when calling spark-submit, but this doesn't work either.
The same problem with adding it to conf/spark-env.sh
The only way I have got this to work is by editing the bin/spark-submit script directly which defeats the purpose of having it read from the existing environment variable and will get overwritten when I upgrade spark.
So it looks to me like spark-submit ignores your current users' environment variables and only allows a restricted subset of variables to be defined in it's conf files. Does anyone know how I can resolve this?
I would like to setup PhpUnit in PhpStorm. I press 1. Edit Configurations... and would like to enter this parameter in field 2.
I am using phpunit.xml as configuration file and all want to use a relative path like:
phpunit.xml
or use project root variable like
$PROJECT_ROOT/phpunit.xml
But both options are not working for me.
Based on your screenshot (the place where you want to use it): use full path -- in project settings such path is stored relative to the project root anyway (unless you specify some file which is outside of the project, of course) and the full path then reconstructed when needed (e.g. when shown to you or when used as a parameter during tests execution).
I don't think you'll be able to achieve what you want via the project's Run/Debug configurations. What might help you is the Default configuration file setting in your default project settings, which can be used to define the PHPUnit configuration file to use by default, so you don't need to specify it via the Use alternative configuration file option in your Run/Debug configuration.
To set this, open your Default Settings window, then navigate to Languages & Frameworks -> PHP -> PHPUnit. In the Test Runner section tick the Default configuration file checkbox and specify the location where you keep your configuration file. If this file will always be in the same path relative to your project root, you can use the $PROJECT_DIR$ variable to define the project root. So if your PHPUnit configuration file is always in the root of your project, you might set this to something like $PROJECT_DIR$/phpunit.xml. When you create a new project, its Default configuration file variable will be set to the file offset from your project root, and you won't need to use the Use alternative configuration file option in your Run/Debug configuration.
If you're opening the same project in different locations on the same machine this should work for new projects without any problem, if you want to share this configuration across machines, you might need to try PHPStorm's Exporting and Importing Settings functionality.
I'm not sure if this directly solves your problem, and it's a few months late anyway, but maybe this will be useful for someone else who stumbles across this question... The above instructions were correct for my 8.0.3 installation on Linux.
I am looking into a way of defining an environment variable for Hudson (NCover path on build server), so that build scripts can use it, but no need to re-define it in Hudson jobs (similar to %SVN_REVISION% or %BUILD_NUMBER%). What would be the way of doing it?
Thank you.
You can set node variables, that will be available to every job that runs on that node. Go to the node configuration page, and you'll see it. For the master node, the environment variables are configured on Hudson's main configuration screen.
If it's global (same on every node), you can add environment variables for every build in Manage Hudson -> Configure System, under Global Properties -> Environment Variables
Updated: Oops, sorry, didn't notice that #Michael Donohue had already said this.
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.