I have my page configuration done via JCR configuration.
I have the component configuration using YAML configuration.
I want to make this component available to the a template configured in the JCR.
The component config is under: /project-website-module/src/main/resources/website-module/components/linkList/linkList.yaml
I tried to reference this in the template's component availability in different ways:
website-module:components/linkList/linkList
website-module:components/linkList/linkList.yaml
/website-module/components/linkList/linkList
/website-module/components/linkList/linkList.yaml
src/main/resources/website-module/components/linkList/linkList
src/main/resources/website-module/components/linkList/linkList.yaml
But no luck, I keep getting the error:
"Caused by: info.magnolia.config.registry.Registry$NoSuchDefinitionException: <pathToComponentConfiguration>"
The component config is under:
/project-website-module/src/main/resources/website-module/dialogs/linkList/linkList.yaml
... that's the dialog config, where's the component config yaml?
Path to the component config not to dialog config is the one that you need to use when referring to the component. And that config file needs to be physically at src/main/resources/website-module/templates/components/... and reference is then website-module:components/....
Also if you have specified module descriptor for the module, name in the module descriptor better match the website-module.
I had to move the YAML component configuration under (notice the templates directory added):
/project-website-module/src/main/resources/website-module/templates
In my case, move linkList.yaml under:
/project-website-module/src/main/resources/website-module/templates/components/linkList/linkList.yaml
Then in the JCR config, use the following path:
website-module:components/linkList/linkList
Note: likewise, YAML dialog configurations must be under:
/project-website-module/src/main/resources/website-module/dialogs
Related
electron-builder generates "latest.yml" blockmap and exe for windows. But in production environment yml is not accepted. Need to change "latest.yml" to "latest.json". What are the configuration require to change "latest.yml" to "latest.json"?
electron-builder#^22.9.1
We tried it , there are no configuration options to change to json.We converted from yml to json at jenkins build . Electron-builder is using js-yaml node module to parse the yml response, which will accept both json and yml. If you send json instead of yml present version of electron-updater will accept and works fine.
I am trying to configure email environment settings in my django project. I am using django-environ package. I have pasted this code:
EMAIL_CONFIG = env.email_url('EMAIL_URL',default='smtp://user#:password#localhost:25')
vars().update(EMAIL_CONFIG)
in my .env file. But when i run the server am getting an error saying:
"django.core.exceptions.ImproperlyConfigured: Set the EMAIL_CONFIG environment variable"
what am getting wrong?
I don't think that this settings should part of your .env. This file should look like this
DEBUG=on
SECRET_KEY=your-secret-key
DATABASE_URL=psql://user:un-githubbedpassword#127.0.0.1:8458/database
SQLITE_URL=sqlite:///my-local-sqlite.db
CACHE_URL=memcache://127.0.0.1:11211,127.0.0.1:11212,127.0.0.1:11213
REDIS_URL=rediscache://127.0.0.1:6379/1?client_class=django_redis.client.DefaultClient&password=ungithubbed-secret
I guess your settings (taken from the docs) should be used inside settings.py or in a custom email_config
EMAIL_CONFIG = env.email_url('EMAIL_URL',default='smtp://user#:password#localhost:25')
vars().update(EMAIL_CONFIG)
Check the installation and usage docs from django-environ.
Referring to official NestJS documentation, it is recommended to use ConfigService in order to use environment variables.
So in the code, we access all vars defined in an .env file with something like:
config.get('PORT')
But it is not recommended to use .env in production environment. So how to deploy in that way?
Why not just use the standard method with dotenv and process.env.PORT?
There are two problems that make the ConfigService less useful.
First
When no .env file is present in any environment, readFileSync in
dotenv.parse(fs.readFileSync(filePath))
will fail:
[Nest] 63403 [ExceptionHandler] path must be a string or Buffer
TypeError: path must be a string or Buffer
at Object.fs.openSync (fs.js:646:18)
at Object.fs.readFileSync (fs.js:551:33)
at new ConfigService (../config/config.service.ts:8:38)
Even if e.g. process.env.API_KEY is available
this.configService.get('API_KEY')
will not return anything. So the ConfigService forces you to use a prod.env file, which dotenv advocates against:
No. We strongly recommend against having a "main" .env file and an
"environment" .env file like .env.test. Your config should vary
between deploys, and you should not be sharing values between
environments.
https://github.com/motdotla/dotenv#should-i-have-multiple-env-files
Second
You have to import the config module and inject the service in order to use it. When you use env variables like this
imports: [
MongooseModule.forRoot(process.env.MONGO_URI, { useNewUrlParser: true }),
ConfigModule,
],
the config service is useless.
Read more about config in the environment here: https://12factor.net/config
But this is not recommended to use .env in production environnement. So how to deploy that way ?
Actually, it is not recommended to commit your .env files. It's perfectly fine to use them in production :-).
Why not use the standard method with dotenv and process.env.PORT?
It allows decoupling your core code from the code responsible for providing configuration data. Thus:
The core code is easier to test: doing some manual changes/mocking of process.env is such - a - pain, whereas mocking a "ConfigService" is pretty easy
You can imagine using anything else than environment variables in the future by just replacing a single method (or a few getters) in a dedicated class, instead of replacing all the occurrences of process.env.* in your code // to be fair, this is unlikely to happen, as using env. variables is the most common way to load configuration data, but still.
Using #nestjs/config (a.k.a. ConfigModule) makes environment variables available to your app whether they come from a .env file or set in the environment. Locally you use a .env file and on production use the environment.
In JMeter I am passing multiple JSON inputs as body, Variable name is defined as JSON_FILE and coming from CSV Data Config
${__FileToString(${__eval(${JSON_FILE})}.json,,)}
CSV Data
designO1015643320
.
.
designO1077673985
designO1088516727
Running load test from Jmeter UI works fine, but running as mvn project is giving error about FileNotFoundException even though .csv file and .json files are in same folder as .jmx file
Error from .jmx.log:
WARN - jmeter.functions.FileToString: Could not read file: designO1015643320.json File 'designO1015643320.json' does not exist java.io.FileNotFoundException: File 'designO1015643320.json' does not exist
Response in .jtl:
httpSample t="4" lt="0" ts="1508530091457" s="false" lb="CreateDesign_PUT" rc="Non HTTP response code: org.apache.jorphan.util.JMeterStopThreadException" rm="Non HTTP response message: End of sequence" tn="Design_APIs 1-1" dt="text" by="1822" ng="1" na="1"/>
JMeter GUI default relative path is the bin folder
Relative paths are resolved relative to the current working directory (which defaults to the bin/ directory).
Maven search in different default path for files src/test/jmeter directory
See guide:
in the src/test/jmeter directory. When running the project, the JMeter Maven plugin searches for tests to run in this directory.
And you can find this path dynamically
I heard Groovy is a new black so I would recommend replacing your __FileToString() function with __groovy() function, the Groovy equivalent of dynamically getting the file path relative to Maven's plugin current working directory would be something like:
${__groovy(new File(org.apache.jmeter.services.FileServer.getFileServer().getBaseDir() + System.getProperty('file.separator') + vars.get('JSON_FILE') + '.json').text,)}
See JavaDoc on FileServer class for more details.
I have ASP.NET Core application (Web Api). The documentation has explained working with multiple environments, however it failed to explain how to set aspnetcore_environment when publishing the web site.
So lets say if i have 3 environments Development, Staging and Production
In classic ASP.NET Web Application i used to create 3 build configurations. Development, Staging and Production ( Like shown in picture below). and then 3 .pubxml files, one for each configuration. Do i need to use the same approach for ASP.NET Core application as well?
How do i set aspnetcore_environment in .pubxml file?
If the approach specified in Question 1 is obsolete, then what's the alternate approach? ( I use Jenkins for CI)
Update 1
I understand that I have to set ASPNETCORE_ENVIRONMENT however I am not able to understand where do we set this? During development I can set this in profile in launchSettings.json, however question was how do we set this when publishing to staging or production? do we set environment variable on the target server itself?
Update 2
I found article here that explains different ways of setting environment variable. This partially answered my question. However when I publish the application, the publish process does not honor the environment variable while publishing appsettings.{env.EnvironmentName}.json
I have created separate post for that question
You could pass in the desired ASPNETCORE_ENVIRONMENT into the dotnet publish command as an argument using:
/p:EnvironmentName=Staging
e.g.
dotnet publish /p:Configuration=Release /p:EnvironmentName=Staging
This will generate out the web.config with the correct environment specified for your project:
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Staging" />
</environmentVariables>
I had the same requirement, and I came up with the following solutions. This works well with automated deployments and require fewer configuration changes.
1. Modifying the project file (.CsProj) file
MSBuild supports the EnvironmentName Property which can help to set the right environment variable as per the Environment you wish to Deploy. The environment name would be added in the web.config during the Publish phase.
Simply open the project file (*.csProj) and add the following XML.
<!-- Custom Property Group added to add the Environment name during publish
The EnvironmentName property is used during the publish for the Environment variable in web.config
-->
<PropertyGroup Condition=" '$(Configuration)' == '' Or '$(Configuration)' == 'Debug'">
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' != '' AND '$(Configuration)' != 'Debug' ">
<EnvironmentName>'$(Configuration)'</EnvironmentName>
</PropertyGroup>
Above code would add the environment name as Development for empty or Debug configuration. For any other Configuration the Environment name would be picked from the configuration which was selected. This will add the ASPNETCORE_ENVIRONMENT environment with the desired configuration. You can modify the logic for environment name as desired by updating the CsProj file. More details here
2. Adding the EnvironmentName Property in the publish profiles.
We can add the <EnvironmentName> property in the publish profile as well. Open the publish profile file which is located at the Properties/PublishProfiles/{profilename.pubxml} This will set the Environment name in web.config when the project is published. More Details here
<PropertyGroup>
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
As shown in above image, environment can be added for each configuration and the name of the EnvironmentName property can be changed in each *.pubxml file.
3. Command line options using dotnet publish
Additionaly, we can pass the property EnvironmentName as a command line option to the dotnet publish command. Following command would include the environment variable as Development in the web.config file.
dotnet publish -c Debug -r win-x64 /p:EnvironmentName=Development
When hosting the application under IIS you can set the environment variable in web.config.
https://learn.microsoft.com/en-us/aspnet/core/hosting/aspnet-core-module
To generate it on publish add a web.config to the root of your project, "dotnet publish" will use this file as the basis for the one that is generated for in the publish folder. Then you can change the value in your deployment system.
<?xml version="1.0" encoding="utf-8" ?>
<!-- Used to overwrite settings web.config generated by "dotnet publish", Only used when hosting under IIS -->
<configuration>
<system.webServer>
<aspNetCore stdoutLogEnabled="true">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
</system.webServer>
</configuration>
I think you can't do it in the publish profile. You have to set environment variable, e.g. ASPNETCORE_ENVIRONMENT = Staging.
I had to do a similar thing with a aspnet core web app on Azure. I wanted to have dev, staging and production. The way I did it was exactly with env variable.
To setup two or more profiles, you need to create additional profile, as mentioned in a linked article, and your launchSettings.json will contain an array:
"profiles": {
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"IIS Express (Staging)": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Staging"
}
}
}
To be able to read the environment variable, you need to specify it during startup and call additional method AddEnvironmentVariables to variables take action:
public class Startup
{
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
// general properties
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
// specify the environment-based properties
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
// do not forget to add environment variables to your config!
.AddEnvironmentVariables();
Configuration = builder.Build();
}
}
Simple way to set it in visual studio IDE.
Project > Properties> Debug > Environment variables
Please do not use environment variables of machine level instead scope
to the application , there is a possibility of other application doing
same, changing may affect other application.