How to un-commit last un-pushed git commit without losing the changes

 git reset HEAD~2 --soft

https://stackoverflow.com/questions/19859486/how-to-un-commit-last-un-pushed-git-commit-without-losing-the-changes

Find a Word in VI editor

https://ccm.net/faq/982-finding-a-word-in-vi-vim

To find a word in Vi/Vim, simply type the / or ? key, followed by the word you're searching for.

Once found, you can press the n key to go directly to the next occurrence of the word.

Vi/Vim also allows you to launch a search on the word over which your cursor is positioned. To do this, place the cursor over the term, and then press * or # to look it up.

ResourceBundle - FileLocation and Classpath

 https://www.programmersought.com/article/44943226090/

ResourceBundle file is read in the classpath, that is, the src or src directory, and we need to be packaged in the project, properties files packed in jar, modify inconvenient, we need to be placed outside the jar file properties you can be modified at any time.

1, generally the default mode ResourceBundel read file is read path CLASSPATH, configuration file named resourceBundle.properties. In the src root directory:

ResourceBundle rb=ResourceBundle.getBundle("resourceBundle")

2, resourceBundle.properties placed in a folder, such as the new config folder,

private static ResourceBundle rb; private static BufferedInputStream inputStream; static { String proFilePath = System.getProperty("user.dir") +"\\config\\resourceBundle.properties"; try { inputStream = new BufferedInputStream(new FileInputStream(proFilePath)); rb = new PropertyResourceBundle(inputStream); inputStream.close(); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } }

Configuration - Externalizing /Externalization

https://reflectoring.io/externalize-configuration/

The Road to Hell: Internal Configuration

The configuration parameters are inside of the deployment artifact, which is why I call this internal configuration.

So what’s wrong with this approach?

First off, this approach doesn’t scale. Each time we’re changing a configuration parameter we have to re-build and re-deploy an artifact. Each time we have to wait for the build to finish before we can test the change.

Basically, it all boils down to this approach being a violation of the Single Responsibility Principle. This principle says that a unit of code should have as few reasons to change as possible.

If we transfer this principle to our deployment artifact, we see that our deployment artifact simply has too many reasons to change. Any configuration parameter is such a reason. A change in any parameter inevitably leads to a new artifact.

A clear indicator for internal configuration is when the build process takes a parameter that specifies a certain runtime environment.

External Configuration to the Rescue

Within each environment lives a configuration that is valid for this environment only. This configuration is passed into the application at startup.

This approach negates all drawbacks of internal configuration discussed above.

• Fixed File Path Directory having config files
• Config Server
• Cmd line
• Environmental Variables

Externalisation of Configuration - Spring Boot --spring.config.location --spring.config.additional-location

https://www.baeldung.com/spring-properties-file-outside-jar

https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html

----------------------------------------------------------------------------

By default, Spring Boot looks for "application.properties", "application.yml" inside

locations defined by "spring.config.location" Application Java Arguments

Note :

-Dfoo.bar=fubar (JVM Arg) (-D)

--foo.bar=fubar (Application Arg) (--)

If If you prefer to add additional locations, rather than replacing them, you can use "spring.config.additional-location"

Spring Boot - will look for Files in these config Locations apart from Usual Config Directories inside the Project and read them and Will be used to fill Values from @Value Annotations at Startup 

@Configuration
public class SystemPropertiesFilepaths {

	@Value("${applicationProperties}")
	private String applicationProperties;

	@Value("${processDetails}")
	private String processDetails;

	@Value("${databaseProperties}")
	private String databaseProperties;
}

  //Getters or Field Level Accessors used to fetch Values 

----------------------------------------------------------------------------

export SPRING_CONFIG_NAME=application,jdbc export SPRING_CONFIG_LOCATION=file:///Users/home/config

java -jar app.jar --spring.config.name=application,jdbc --spring.config.location=file:///Users/home/config

----------------------------------------------------------------------------

Using the Default Location

By convention, Spring Boot looks for an externalized configuration file – application.properties or application.yml – in 4 predetermined locations in the following order of precedence:

• A /config subdirectory of the current directory

Using the Command Line

We can also pass a folder location where the application will search for the file:

java -jar app.jar --spring.config.name=application,jdbc --spring.config.location=file:///Users/home/config

Using Environment Variables

Or, let's say that we can't alter the start-up command. What's great is Spring Boot will also read the environment variables SPRING_CONFIG_NAME and SPRING_CONFIG_LOCATION

export SPRING_CONFIG_NAME=application,jdbc
export SPRING_CONFIG_LOCATION=file:///Users/home/config
java -jar app.jar

2.3. External Application Properties

Spring Boot will automatically find and load application.properties and application.yaml files from the following locations when your application starts:

1. The classpath root

2. The classpath /config package

3. The current directory

4. The /config subdirectory in the current directory

5. Immediate child directories of the /config subdirectory

The list is ordered by precedence (with values from lower items overriding earlier ones). Documents from the loaded files are added as PropertySources to the Spring Environment.

If you do not like application as the configuration file name, you can switch to another file name by specifying a spring.config.name environment property. You can also refer to an explicit location by using the spring.config.location environment property (which is a comma-separated list of directory locations or file paths). The following example shows how to specify a different file name:

$ java -jar myproject.jar --spring.config.name=myproject

The following example shows how to specify two locations:

$ java -jar myproject.jar --spring.config.location=optional:classpath:/default.properties,optional:classpath:/override.properties

Use the prefix optional: if the locations are optional and you don’t mind if they don’t exist.

spring.config.name and spring.config.location are used very early to determine which files have to be loaded. They must be defined as an environment property (typically an OS environment variable, a system property, or a command-line argument).

If spring.config.location contains directories (as opposed to files), they should end in / (at runtime they will be appended with the names generated from spring.config.name before being loaded). Files specified in spring.config.location are used as-is. Whether specified directly or contained in a directory, configuration files must include a file extension in their name. Typical extensions that are supported out-of-the-box are .properties, .yaml, and .yml.

When multiple locations are specified, the later ones can override the values of earlier ones.

Locations configured by using spring.config.location replace the default locations. For example, if spring.config.location is configured with the value optional:classpath:/custom-config/,optional:file:./custom-config/, the complete set of locations considered is:

1. optional:classpath:custom-config/

2. optional:file:./custom-config/

If you prefer to add additional locations, rather than replacing them, you can use spring.config.additional-location. Properties loaded from additional locations can override those in the default locations. For example, if spring.config.additional-location is configured with the value optional:classpath:/custom-config/,optional:file:./custom-config/, the complete set of locations considered is:

1. optional:classpath:/

2. optional:classpath:/config/

3. optional:file:./

4. optional:file:./config/

5. optional:file:./config/*/

6. optional:classpath:custom-config/

7. optional:file:./custom-config/

This search ordering lets you specify default values in one configuration file and then selectively override those values in another. You can provide default values for your application in application.properties (or whatever other basename you choose with spring.config.name) in one of the default locations. These default values can then be overridden at runtime with a different file located in one of the custom locations.

Add Key and cert in CURL

https://downey.io/notes/dev/curl-using-mutual-tls/

curl --cert 'abc.com_digicert_sha2_secure_server_ca_.pem' \
--key 'abc.com_digicert_sha2_secure_server_ca_.pkcs8' \
--location --request POST 'https://demo--test.my.salesforce.com:8443/services/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: BrowserId=4jzphkElEeu76TsJSxG4Tw' 

curl --cacert ca.crt \
     --key client.key \
     --cert client.crt \
https://cloud-controller-ng.service.cf.internal:9023/internal/v4/syslog_drain_urls

Exporting CER and KEY file to PFX File - SSL

[rage@az-cvs-li-re-001 ~]$ cd Playground/

[rage@az-cvs-li-re-001 Playground]$ openssl pkcs12 -export -in linux_cert.pem -inkey privateky.key -out output.pfx

Enter Export Password:

Verifying - Enter Export Password:

[rage@az-cvs-li-re-001 Playground]$ ls

linux_cert.pem  output.pfx  privateky.key

[rage@az-cvs-li-re-001 Playground]$