making persistent carbon.xml changes - configuration

How can I made persistent changes in carbon.xml after server reboot?
No matter what I change, after wso2 restart my modified carbon.xml is sent to a "backup" directory, and replaced with the "out of the box" carbon.xml file.

With the 4.5.0 carbon-kernel release, all WSO2 products such as APIM 3.0.0, IS 5.9.0 introduced a new config model. According to the new config model, there is a centralized configuration file (deployment.toml) where users add the configurations, then those configurations will be added to the respective .xml files.
So if you want to do some changes in the carbon.xml file, you have to add the relevant configs in deployment.toml file according to the new config model. With the new config model, all the changes made by you in the xml config files will be overridden by the toml configs during the server startup.
The previous configurations moved into "backup" folder when you make a new change in the deployment.toml file. This backup folder is used as a backup for the previous configs.
Please follow this documentation to refer further information on this new config model
Related documents:
https://wso2.com/blogs/thesource/2019/10/simplifying-configuration-with-WSO2-identity-server

In my case I was using WSO2 API Manager 3.1.0 and I wanted to update the <XSSPreventionConfig> tag in carbon.xml file. Yes, for every restart, my changes in carbon.xml get overriden by auto-generated carbon.xml file with config values coming from deployment.toml.
Then I found out that there are Jinja2 template files (.j2) in this location used to auto-generate XML files and fill them up with values from deployment.toml. wso2am-3.1.0/repository/resources/conf/templates/repository/conf/
I updated carbon.xml.j2 directly for my <XSSPreventionConfig> changes and it works perfectly fine.

Related

unable to configure through carbon.xml

I am trying to configure wso2 by modifing its configuration file named "carbon.xml", but no matter what change I do to "carbon.xml", even adding a single "white space" or modifying a comment it's enough for the wso2 server to reset carbon.xml file to it´s original "out of the box" state.
I tryied to protect the file carbon.xml by dropping write permissions, but in this case wso2 server refuses to start, it aborts execution and displays an error complaining that it was not able to "write new configuration" !!!
Does any one know how to solve this?
I found the answer, In wso2 version 5.9 there is a new centralized configuration file, named "deployment.toml". Configurations must be done in this file and then wso2 propagates changes to the respective configurations files, like carbon.xml or catalina-server.xml, for example.
If you delete "deployment.toml" wso2 will fallback to previos behavior.
With the new 4.5.0 carbon-kernel release, all WSO2 products such as APIM 3.0.0, IS 5.9.0 introduced a new config model. According to the new config model, there is a centralized configuration file (deployment.toml) where users add the configurations, then those configurations will be added to the respective .xml files.
This new config model was introduced in order to simplify the configuration (previously there were a lot of configuration files) and to increase the user experience. Please follow this documentation to refer further information on this new config model
Related documents:
https://wso2.com/blogs/thesource/2019/10/simplifying-configuration-with-WSO2-identity-server
https://is.docs.wso2.com/en/next/references/new-configuration-model/
If you have a deployment.toml file, the changes directly made into the xml files will be overiden during the server startup. Deleting the deployment.toml file will use the old config model. But it is not a recommended approach.

How can I define an arbitrary file outside my web application to configure log4j2

My web application will be deployed to Weblogic application servers on Windows and Linux/Unix in different environments. The log file location, appenders and log levels will vary between the different deployments and we would like to be able to change the logging configuration during runtime (by exchanging the config file), so I cannot embed a log4j2.xml (or whatever other config file) into my deployment. And since I'm running on Application servers I cannot control, I've got no chance to add environment variables to point to another configuration Location.
Currently, my log4j2.xml resides in the classpath of my application and is being packaged into my war file. Is there any way to tell Log4J2 to use a configuration file e. g. relative to the application root (like Log4J's configureAndWatch(fileLocation) method)?
I found lots of examples of how to configure Log4J2, but everything I found about the config file location points to the applications class path.
I finally found a solution for my problem. I added a file named
log4j2.component.properties
to my project (in src/main/resources). This file contains a property pointing to the location of my log4j2 configuration file:
log4j.configurationFile=.//path//on//my//application//server//someLog4j2ConfigFile.xml
This causes log4j2 to read that file and configure itself from it's content.

eXist-db change database files location

I am running eXist-db in servlet mode deployed on an WildFly 10 application server. But after redeploying the eXist-db WAR-file, all stored data is gone. So I want to change the path where the database data is stored. Currently it should be stored in "standalone/tmp/vfs/temp/..." but this dir is deleted on undeploying right?
eXist's default data directory is $EXIST_HOME/webapp/WEB-INF/data, but it can be changed to a different directory, i.e., a directory outside the $EXIST_HOME directory, by editing $EXIST_HOME/conf.xml under db-connection/#files. See the eXist documentation about the conf.xml configuration file here: https://exist-db.org/exist/apps/doc/configuration.xml#D2.2.4.6

How to update OJS

Would you please let me know how to update OJS (Open Journal System). I have installed it on a shared server and I have no access to the shell, only a web interface and control panel (direct admin) is allowed. I think there must be some update button online, But i could not find it.
Thanks
Download and decompress the package from the OJS web site
Make a copy of the config.inc.php provided in the new package
Move or copy the following files and directories from your current OJS
installation:
config.inc.php
public/
Your uploaded files directory ("files_dir" in config.inc.php), if it
resides within your OJS directory
Replace the current OJS directory with the new OJS directory, moving the
old one to a safe location as a backup
Be sure to review the Configuration Changes section of the release notes
in docs/release-notes/README-(version) for all versions between your
original version and the new version. You may need to manually add
new items to your config.inc.php file.
The easiest thing would be to make a new folder on your shared hosts with the latest version. Copy over the config.ing.php, cache, and public folders. If your files is within your OJS folder as well, copy it too (though, you should move it outside the web accessible location).
Then you'll find an option to upgrade the database in the Admin pages.

app.config for a windows service doesn't work on the fly

I wrote a Windows Service program, say myService.exe and it has myService.exe.config file. But it seems changes to the app.config is not repected by the service until the service is restarted. So, is this by design? Or how could I make my service always respects the config file change without restarting?
Thanks!
This is by design, it doesn't work the same as a web.config file.
You can use a FileSystemWatcher object to monitor for changes to the config file, and take an appropriate action if the file changes.
Yes, any .NET console/Winforms/Windows Service application will read its corresponding config file at startup and cache its contents. Altering it while the app is running typically doesn't change the running app.
If you need this kind of feature, you'd have to implement that yourself - e.g. make the app re-check the config periodically, or respond to a filesystem-watcher event that the file has changed.