I have a fairly standard OTP setup with rebar and reltool. I've setup reltool to use a vars.config to swap in overlay template variables with {overlay_vars, "files/vars.config"}. I've noticed that variables other than what I have listed in vars.config also work as overlay template variables, the most obvious one of which is {{erts_vsn}}.
I assume there are other built-in variables; how do I find what they are? I've combed the reltool docs and come up with nothing.
I believe that your answer is in Rebar's rebar_reltool module.
There, you find the definition for:
erts_vsn
rel_vsn
target_dir
Related
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
I played around with Hyperledger Fabric lately and I'm not able to find a good and exhaustive description of ALL environment variables one can set on the hyperledger fabric docker containers (fabric-orderer, fabric-peer, fabric-ca, fabric-tools, fabric-kafka, ...)
Is there such a documentation? I only find so little about the possible variables and what their different values would do and when one would choose which value; even on the official documentation.
Can anyone provide such a list with explanation? Or can we collect information to create such a list?
Ideally, I would like to have something like the following:
fabric-orderer
ORDERER_GENERAL_GENESISMETHOD
values: file, provisional (default)
file is used when you want provide the genesis block as file to the container (see ORDERER_GENERAL_GENESISFILE)
provisional is used when ...
ORDERER_GENERAL_GENESISFILE
value(s): path to genesis file path
fabric-peer
some env var
... explanation ...
Here's also a sample list of some env variables I've seen other people using and don't why, what it means or if it even works:
ORDERER_GENERAL_LEDGERTYPE
ORDERER_GENERAL_BATCHTIMEOUT
ORDERER_GENERAL_MAXWINDOWSIZE
CONFIGTX_ORDERER_KAFKA_BROKERS
ORDERER_GENERAL_LISTENADDRESS
ORDERER_GENERAL_PORT
ORDERER_GENERAL_HOST
...
I hope asking this question here is ok (it's my first).
Thanks a lot for your help!
This is a great question, and would indeed make a good addition to the docs. It is not currently explicitly documented, but I can explain at least how you can determine what the variables are.
We use viper for managing configuration. We ship a sample configuration with the distribution of the docker images and binaries. As you can see, there are three configuration yaml files: configtx.yaml, core.yaml and orderer.yaml. For each configuration parameter in the yaml file, you can derive an environment variable that can be used to override the value in the config file used at startup. The environment variable name is derived from the filename (e.g. CORE for core.yaml), and underscore-separated capitalization of the nested properties in the config, (e.g. CORE_LOGGING_LEVEL).
The sample apps provided contain docker-compose yaml configurations that leverage most of the properties you might consider leveraging for your own purposes.
Meanwhile, I have created a JIRA to track this and invite contributions to help us flesh out an addition to our documentation that provides a useful reference.
I have a lua project with lua files specified in multiple directories all under the same root folder with some dependencies.
Occasionally I run into issues where when a table is being loaded at load time I get a nil exception as the table is referencing a not yet initialised table, like:
Customer =
{
Type = CustomerTypes.Friendly
}
Which causes a nil exception for CustomerTypes as CustomerTypes.lua has not yet loaded.
My current solution is to simply have a global function call in these lua files to load the dependency scripts.
What I would like to do is pre-process my lua files to find all dependencies and at run time load them in that order without needing function calls or special syntax in my lua files to determine this (i.e. the pre-processor will procedurally work out dependencies).
Is this something which can be realistically achieved? Are there other solutions out there? (I've come across some but not sure if they're worth pursuing).
As usual with lua there are about 230891239122 ways to solve this. I'll name 3 off the top of my head but I bet I could illustrate at least 101 of them and publish a coffee table book.
First of all, it must be said that the notion of 'dependencies' here is strictly up to your application. Lua has no sense of it. So this isn't anything like overcoming a deficiency in lua, it's simply you creating a scripting environment in your application that makes you comfortable, and that's what lua's all about.
Now, it seems to me you've jumped to a conclusion that preprocessing is required to solve the given problem. I don't think that's warranted. I feel somewhat comfortable saying a more conventional approach to solving the problem would be to make a __newindex metamethod globally which handles the "CustomerTypes doesnt exist yet" situation by referencing a list of scripts which have been scanned out of the filesystem initially for one called CustomerTypes.lua and running that.
But maybe you have some good reason for wanting it done strictly as preprocessing. In your case, I would start by considering 'dependencies' to be any name which is a script found in your scripts filesystem. Then scan each script to look for the names of dependencies using the definitions/list you just created, and prepend a load(dependency) command to each of those scripts.
Since the concept of "runtime" or "preprocessing" is somewhat ambiguous in this context, you might mean at script-compile-time. You could use the LuaMacros token filters system to effect a macro which replaces CustomerTypes with require("CustomerTypes.lua") or something to that effect after having discovered that CustomerTypes is a legal dependency name.
Setup: Portable editions of Sublime Text 2 with its plugin Sublimelinter and node.exe.
sublimelinter_executable_map has to set in a way so that Sublimelinter uses node.exe as JavaScript engine.
Could one do this using a relative path instead of a fully qualified path?
Trying with different forms of relative paths as given in MSDN, the plugin failed to detect node.exe. The console message i got was SublimeLinter: javascript disabled (One of the following JavaScript engines must be installed: node.js, JavaScriptCore)
Your GitHub issue on this topic:
https://github.com/SublimeLinter/SublimeLinter/issues/612
Is a duplicate of these:
https://github.com/SublimeLinter/SublimeLinter/issues/611
https://github.com/SublimeLinter/SublimeLinter/issues/459
This seems to be a hot topic.
I forked the repository and started to code a patch for you, which seems to center around this segment:
https://github.com/SublimeLinter/SublimeLinter/blob/4ef4b2ca08e0224b8af59bf3406c4927432efb94/sublimelinter/modules/base_linter.py#L380
But then, it dawned on me... environment variables. Since this seems to be a prevalent issue with many unsolved requests, it seems that you ought to set the PATH environment variable, and place the location you are looking to be found first, earlier in that variable.
Don't know your Windows version, and the process to set an environment variable will be different for your version, so you ought to experiment with that, and then use that method as the standard for all your environments ( as it seems implied you have more than one to maintain ).
Update: Ruby seems to allow relative paths, but JavaScript does not, because of this section:
https://github.com/SublimeLinter/SublimeLinter/blob/4ef4b2ca08e0224b8af59bf3406c4927432efb94/sublimelinter/modules/base_linter.py#L380
Which hinges on: JAVASCRIPT_ENGINE_WRAPPERS_PATH
So the answer is, unless that code is adapted, no. Relative paths cannot be used for JS.
if yes, how to change such variable?
should i modify vimrc? but vimrc is in $VIMTIME, if i changed it, how vim find it?
i maybe have lots copies of VIMRUNTIME, and i hope that i can switch to different VIMRUNTIMEs easily, how to make this done.
anybody here who have ever tried to do this?
btw, there are lots of .vim files inside $VIMRUNTIME, are they all vim plugins? is .vim files all writen in vimscript? what vimscript can do and what it cannot? why not all vim plugins implemented using .vim? since i find some vim plugin also use script language such as perl or python...
The gory details are documented under :help startup, but you rarely need to modify $VIMRUNTIME. You didn't mention why you would want to do this, but it's probably a bad idea.
If you don't want to set the VIMRUNTIME environment variable in the shell from which you launch Vim, you can modify it in a user-specific ~/.vimrc (via :let $VIMRUNTIME = '/path/to/it'), because that one is read before the system-wide configuration.
The runtime files contain the help documents, default configuration, filetype detections and syntax highlightings. You can add your own extensions (e.g. downloads from http://www.vim.org) in ~/.vim/.... As I said, there should be no need to mess with the system-wide runtime; this is managed by your system's package management.