We develop applications/sequences on Windows laptops but the ESB servers are Linux based. In case we have to deal with handling files we store them in a temporary location. Windows and Linux have different filesystems and using hardcoded locations works on one platform but not the other.
How can I create and use a kind of TempLocation environment variable, registry entry or else that we can use but that does not change after deployments or server restarts or cause conflicts between applications.
Regards,
Paul
I don't know what your goal for store the files? But I think you maybe can use the carbon home. You can create the "tempFiles" folder under your Linux and Windows ESB home. Then use the CarbonUtils get the the carbon home.
String carbonhome = org.wso2.carbon.utils.CarbonUtils.getCarbonHome();
You may need use the File.separator for append the folder path.
String tempPath = carbonhome + File.separator +"tempFiles";
Then use the Java IO store your files on this folder. But you may need proper access for this folder.
In case you need the Maven dependency for CarbonUtils
<dependency>
<groupId>org.wso2.carbon</groupId>
<artifactId>org.wso2.carbon.utils</artifactId>
<version>4.2.0</version>
</dependency>
Related
Is there a way to change the location of the tmp directory ember-cli is using to process trees? (without using symlinks)
I am trying to develop an ember app using a linux VM on a windows host. Shared folders of any type (be it virtualbox shared folders, nfs or smb) are slow, don't allow symlinks and ember-cli produces a lot of files in the tmp directory. Being able to move this tmp to the native filesystem of the VM would help a lot.
This should be easily configurable, but i couldn't find any configuration option that would allow it.
No. Nobody answered and the help of the ember-cli build doesn't show that parameter.
How about creating a RAMDisk and hardlinking your project tmp folder to it? In Windows this can be done as follows:
Create RAM DISK with imdisk
mklink /j "C:\project\tmp\" "H:\ember-tmp" where C:\project is your local project folder and H: is your RAM Disk.
I'm afraid I don't know the Linux equivalents but it should be easy enough to find. Apparently this can roughly halve your build times with no chance of losing data.
Information sourced from https://emberjs-developer.quora.com/How-to-make-Ember-js-CLI-ember-s-32-times-faster and kudos to Stefan Penner for the suggestion.
Note the link folder MUST already exist before you run mklink otherwise you get the misleading message "Local volumes are required to complete the operation" and the link destination (junction folder) MUST NOT exist otherwise you get the message "Cannot create a file when that file already exists".
Note as of Ember 3.0 you can now change the cache by doing the below
BROCCOLI_PERSISTENT_FILTER_CACHE_ROOT=/path/to/my/other/tmp/
This will output the broccolli files to the path of your choosing. You will need to do the tidy up operation yourself on this custom path
More information here
https://github.com/stefanpenner/async-disk-cache/issues/35
I was wondering whether there is a convention for storing config files in c++. At the moment I am storing the config files in the same directory as the source code that uses them. When building I make sure via the CMakeLists to copy them to the correct location so I can just access them in a relative way (e.g. "config.cfg" iso "/foo/bar/config.cfg) for convenience.
The practice for config files is non portable and operating system dependent. You have also to ask yourself if your configuration is defined per installation/system or per user.
In general, it is a very bad idea to store config in the same directory as your execuable, at least once the developpement is finished. In general executables may be shared between several users and should therefore for security reasons be located in directories that are write-protected for everybody but the system administrator.
For unix/linux, you could for example consider:
/etc or a subfolder thereof, if your configuration is per installed system,
~/ if it's user defined configuration. The usual practice would be to start the filename with a dot. This article will tell you more.
For windows systems, you should consider:
the usual approach now, goes to the registry. Of course, this uses the windows api and is fully non portable.
a subfolder of C:\ProgramData or C:\Users\All users\AppData\Local if your configuration is per installed system,
a subfolder of C:\Users\%USERNAME%\AppData\Local for the users's own configuration.
This SO questions shows how to find the right folders.
Currently I am messing around with a Click-Once WPF application. That application is some third-party application that was not developed by me. I also do not have access to its sources.
It is run on a Windows server periodically and automatically (using a self made launcher written in standard C++) by executing the corresponding *.appref-ms link that was placed in the start menu path on installation of the application. This works fine.
Due to periodically arising problems with that application my launcher needs to wipe all configuration files before starting it so I get a well defined run at all times. Those files are placed in one of the application's folders. That config path for its settings reads like this (I found it by searching the AppData tree manually):
C:\Users\<UserName>\AppData\Local\Apps\2.0\Data\WM4WPKCW.P5Z\67QVXD6C.0NT\<app>_f6187a2321850a68_0003.0004_1a67f9f1633c43fc\Data\AppFiles\
Please note that this config path is pretty different from the application path (which uses differently named folders):
C:\Users\<User>\AppData\Local\Apps\2.0\5HN2CKMO.MPL\YOL20MYR.O8L\<app>_f6187a2321850a68_0003.0004_f6ab8c93b3a43b7c\
Since this config path changes on each update of the Click-Once application I need to find it by code (preferably C++) automatically. Unfortunately I could not figure out a way to do this.
How can I make my launcher find the config path of the Click-Once application based on its *.appref-ms file?
From Raghavendra Prabhu’s blog entry “Client Settings FAQ”:
” If you want to get to the path programmatically, you can do it using the Configuration Management API (you need to add a reference to System.Configuration.dll). For example, here is how you can get the local user.config file path:
Configuration config =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
Console.WriteLine("Local user config path: {0}", config.FilePath);
The code is C# (evidently), but shouldn't be that hard to translate to C++/CLI.
Raghavendra Prabhu further writes:
” If you need to store the settings in a different location for some reason, the recommended way is to write your own SettingsProvider. This is fairly simple to implement and you can find samples in the .NET 2.0 SDK that show how to do this. Keep in mind however that you may run into the same isolation issues mentioned above .
Disclaimer: I have not tested any of this.
If you have an application which relies on another app being installed, you ideally want your installer to find that dependency path automatically. On Windows you can use the registry but what about Mac/Linux? In this particular case it's a C++ application, if that makes a difference.
If you try to distribute your application through any of the common package managers on Linux (apt, yum) you can add the application as a dependency.
If you down the route of custom install scripts you need to resort to some kind of hackery. Either find out which package manager is in use on the system and try to query with it (which can fail, if the other application was installed without the package manager) or try something like which required_app.
Go for the first, if you want to do it right.
In Mac OS X, if you're looking for an application that's bundled in a typical .app bundle, you can use Spotlight to find it from its bundle ID using the command line utility mdfind(1). For example, to find out if Firefox is installed (and where), run this command:
mdfind 'kMDItemCFBundleIdentifier == org.mozilla.firefox'
Generally, on UNIX systems you can expect all programs to reside in $PATH instead of being distributed in a hodge-podge collection of stupidly named and partially localized directories. So, essentially you don't need to find any dependency path - you just call the other "app" (program) via execvp, and the libc takes care of walking through the entries of $PATH and finding the executable.
In the classic UNIX model, you don't check anything in an installer, but just check at runtime whether an executable is available (with which, for example) or not.
The equivalent of a Windows Installer is the Linux Package Manager. The Package Manager handles dependencies and installs it (if it is not already present on the system). The dependency information for an application is stored within the package file. Each distribution has its own Package Manager, though the concept is the same.
There are plenty of resources online for specifics about a Package Manager. However, if you would like to get an overview in comparison with a Windows Installer, check out application management in GNU/Linux for Windows users.
What is recommended way to keep a user configuration data in Unix/Linux?
My programming language is C++. Configuration data will be kept in XML/text/binary format, I have no problem with handling such files. I want to know where can I keep them. For example, in the Windows OS configuration data may be kept in the Registry (old way) or in user application data directory. What about Linux?
I need read/write access to configuration files.
The concept of the registry is peculiar to Windows, and Microsoft once admitted to it being ill-conceived (see this, this, this, this (see #2), and this).
In Unix and Linux, configuration for system-wide programs is in /etc or maybe an application-specific subdirectory.
Per user configuration data are kept in the user's home directory in a hidden file—in text format—or an application-specific hidden directory in the user's home directory. The proper way to reference the home directory is through the environment variable HOME. Hidden files and directories are created by making . the first character of the name.
Examples for system-wide configuration is /etc/wgetrc and /etc/ssh/. Examples of per-user data are $HOME/.bashrc and $HOME/.mozilla/.
The XDG Base Directory Specification specifies where configuration and other files should be stored in Linux and other X-based operating systems:
http://freedesktop.org/wiki/Specifications/basedir-spec
This is the modern way, and may eventually reduce the dotfile mess in the typical user's home directory.
Dotfiles are the classic Unix solution. If you want to deal with reading/writing everything yourself, go for it.
However, most modern programs I use have used GConf for storing preferences. It makes a lot of things easier, both as a developer and as a user (and apparently as an administrator, but I have no experience there).
That depends a little on your flavor of Linux but as a general rule most programs have the system default configuration somewhere in /etc with .config files in your home directory that can override the defaults in the /etc dir.
Great point .config should be .[Name of config file]