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.
Related
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.
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.
I am using SonarQube 4.0 . I try to created a project and run sonar-runner successfully I could see most metrics there.
But when I try to add widgets for LCOM4, RFC and Package design (to show the package tangle index), it shows "No data".
I am not sure what's wrong with my configuration, should I turn on some configuration or install some additional plugins to show LCOM4, RFC and Package tangle index?
I am running sonar-runner on plain file folder (not from SCM , didn't have POM file) , not certain if this is the cause.
If anyone has idea about this problem?
You must analyze .class files.
If you have not already done it, here is the parameter to add to your analysis configuration
# Comma-separated paths to directories with binaries (optional), in case of Java - directories with class files
sonar.binaries=build/classes
I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.
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.