Develop Reference

How to configure Spring Boot datasource part to use in production?

I'm writing my first "real" applicaion in my first job. I could deploy my app using Spring Boot and it works just fine. One thing that i doubt is datasource config part. Now i write all datasource config in application.properties file:
spring.datasource.url = jdbc:postgresql://10.60.6.34:5432/postgres
spring.datasource.username = *username*
spring.datasource.password = *password*
spring.jpa.hibernate.ddl-auto = update
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.PostgreSQL94Dialect
And that's it! What else should i do to make my app production ready? What about connection pooling and all that stuff? (i'm not quite familiar with all that datasource config stuff) Thanks in advance!

So Joe W is not wrong - profiles is an OK way to handle this issue. However, what I'd recommend instead is to handle the issue using environment variables. This will make your application compatible across not only all operating systems (which profiles will too), but will also allow you to run it within Docker (containers) more easily. You will need to do some amount of this anyway, since profiles still requires you to specify which profile you're running, which you'll need to do with an environment variable.
Luckily for you, Spring Boot auto-wires environment variables with no extra work on your side. You can read more about this here: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
When dealing with environment variables, you use underscores instead of periods, so your configs would look like this:
SPRING_DATASOURCE_URL = jdbc:postgresql://10.60.6.34:5432/postgres
SPRING_DATASOURCE_USERNAME = *username*
SPRING_DATASOURCE_PASSWORD = *password*
SPRING_JPA_HIBERNATE_DDL_AUTO = update
SPRING_JPA_PROPERTIES_HIBERNATE_DIALECT = org.hibernate.dialect.PostgreSQL94Dialect
Then you can set your environment variables to whatever you want, and you don't need to worry about pulling in new profiles for each server. In addition, since environment variables are higher in the hierarchy than file-based configurations, you can leave your current file-based configurations alone (if you'd like) and your environment variables will override them when you deploy.
Around your connection pooling, this is going to heavily depend on your backing servlet container (I.e., tomcat vs other) and your backing database (looks like postgres). I'd recommend you look at tomcat-jdbc usage with Spring boot, which will then allow you to configure the things like max connection pools and such within Spring's environment variables as well.

You should take advantage of SpringBoot profiles that will allow you to define separate configuration for dev, stage, prod, and any other environment you want based on a property.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html
A profile gives you a way to control which configuration is loaded based on a property that defines where the application is deployed.
Your question on data connection pooling depends on your backing data storage selection and how that particular storage is setup. In general, when you go to production you should be using connection pooling of some kind but how much and what kind depend on your implementation.

Additionally, you can use spring config service . Config-service is central location(which can be more secure) for all properties and with very minimal configuration/change your spring-boot application can read properties from config-service.

You should provide your database parameters as environment variables then set them in your application.properties as placeholders. For example:
spring.datasource.url=${DATASOURCE_URL}
Where DATASOURCE_URL is one of the env. variable.
In your IDE you set them in the project setting (for example)
So at your work you set your local parameters in IDE, and on the production machine you set prod parameters as environment variable.

Multi tenancy with Spring boot

I'm planning to work on a multi-tenancy application and for now I'm just looking at different implementations on the web to understand the requirements needed to implement such task.
Hibernate + Spring boot are the technologies I'm planning to use.
From my readings, all the different tutorials are using the same approach which is to declare the data sources in a config file so that session factories are launched with the boot of the application, but I really want to have a higher level of the app, where I can add tenants dynamically and input their data sources informations.
This way the application can get the information of the new tenant without the need to touch the config files and re-boot the app.
I thought about having a separate database where I can store my tenants data source credentials or something like that. Can you give me another approach to solve this requirement or a link to an existing implementation that I can refer to.
Thanks

I got similar requirements in the past.
I implemented DataSource proxy class. The class has tenant resolver and a map of simple DataSources. All the places where we need a DataSource use the proxy.
On any method call e.g. getConnection() it resolves tenant, check whether the map contains already created DataSource (if not a new DataSource is created for the tenant and stored in the DB). Then the same method of real DataSource from the map is invoked.
Tenant resolver is ThreadLocal based where tenant value is stored in a filter (got tenant from request header) and used in the DataSource proxy.

What you need to do is using dynamic datasource routing of Spring Framweork via AbstractRoutingDataSource. This answer explains all for you.

In my question.I implements MultiTenantConnectionProvider and CurrentTenantIdentifierResolver.And use DataSourceLookup to choose datasource by tenant.This links is helpful to me.

Here is a full working example of a database-per-tenant multitenat app I built using Spring Boot 2, Spring JPA (Hibernate), Spring Security 5 running on MySQL.
I have explained how it all works and have shared the entire code too.
Take a look here.

Store properties in database, but override locally

Currently, we store our application's environment properties in a .properties file in the WEB-INF. We want to move them to a database table. But we still want to specify the jndi name, and when running in our test environment locally, we want to be able to override certain properties just for our workspace for test and development.
Apache commons' DatabaseConfigurator seemed nice, but wouldn't play nice with the jndi name being defined as a property in the file. Nothing I did to ask it to look at the property file first worked.
I decided to subclass apache commons' AbstractConfiguration to try to create a single configurator that would check the file and database as I wished, but again, it didn't really work. Spring wants that jndi name absolutely first, probably because the data source has to be passed into the configurator as a parameter.
How can I get what I am after here? Mostly properties in the database, but those that are in the file override them. And jndi name for the datasource should not have to be hardcoded in the spring config.

Why don't you write a ApplicationContext listener that will read the configuration from your DB and inject them in the JNDI? Then you can override the configuration in the JNDI with a context.xml file that will be placed in the src/local/webapp/META-INF/.
This is how we get this working in our webapp.

How to connect java application to database using JNDI?

I am implementing JNDI concept to get a connection to Database. I googled to get the starting point, however didn't get it.
The things that i want to do is have a simple java standalone application which used JNDI concept for getting connected to a database.
Sample source that i have is:
DataSource dataSource = null;
Context context = null;
try {
context = new InitialContext();
dataSource = (DataSource) context.lookup("database_connection");
}
catch (NamingException e) {
System.out.println("Got naming exception, details are -> " + e.getMessage());
}
Now, where we define database_connection? Is that defined in an xml file, and if so where do we specify that and what format of that is?
If any pointers can be provided, that would be great.
Thanks

The real difference between your question and the examples is that you're using a standalone Java application. Pretty-much every example assumes that you're running within a Java EE application container. In that case you define the database connection to the container, use JNDI to get the DataSource, and get the connection from that.
When you do a JNDI lookup to get your DataSource, the JNDI framework looks for an initial context factory (a class that implements InitialContextFactory). In your Java EE application, the container provides that. In your standalone Java application, the initial context is null, and no further lookups resolve correctly.
One of the ways you can resolve this is to create your own initial context factory:
public class MyContextFactory implements InitialContextFactory
and inject that into JNDI at startup:
System.setProperty(Context.INITIAL_CONTEXT_FACTORY, "mypackag.MyContextFactory");
and then return a new ObjectFactory from the getInitialContext call, and then implement the ObjectFactory to return a DataSource (also probably custom) from the getConnection() call.
That would all work, but it's overkill. It would be easier to just use the normal JDBC connection string approach to get a connection directly in your application rather than trying to use a DataSource. Or use a framework like Spring to inject it for you or to separate the database connect information from the code (in which case you're using Spring configuration files rather than JNDI directly).
The one reason I'd advocate creating a custom context factory and data source approach is if you have common JPA code that you want to run both within a Java EE app and within a standalone app (it's otherwise non-trivial to configure the same code to do both). That doesn't sound like your case.
So, since you're standalone and not in a Java EE container, I think your real answer is that your use case is not appropriate for a DataSource (unless you move to a framework like Spring that would provide one).

There's a nice tutorial for that here and here
The database should be defined somewhere (LDAP)? There's a series of old articles using the directory service with JNDI (ultimately in your case to get the server information) here.
A nice introduction to naming services here

Strategies for java webapp configuration

Part of my webapp involves uploading image files. On the production server, the files will need to be written to /somepath_on_production_server/images. For local development, I want to write the files to /some_different_path/images.
What's the best way to handle these configuration differences?
One important requirement is this: I don't want to have to mess with the production server at all, I just want to be able to deploy a war file and have it work. So I don't want to use any technique which will require me to mess with the environment variables/classpath/etc. on the production machine. I'm fine with setting those on my local machine though.
I'm imaginine two possible general approaches:
loading a special "dev" configuration file at runtime if certain conditions are met (environment variable/classpath/etc)
flipping a switch during the build process (maven profiles maybe?)

Simple things like a String can be declared as environment entries in the web.xml and obtained via JNDI. Below, an example with an env-entry named "imagePath".
<env-entry>
<env-entry-name>imagePath</env-entry-name>
<env-entry-value>/somepath_on_production_server/images</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
To access the properties from your Java code, do a JNDI lookup:
// Get a handle to the JNDI environment naming context
Context env = (Context)new InitialContext().lookup("java:comp/env");
// Get a single value
String imagePath = (String)env.lookup("imagePath");
This is typically done in an old fashioned ServiceLocator where you would cache the value for a given key.
Another option would be to use a properties files.
And the maven way to deal with multiple environments typically involves profiles and filtering (either of a properties file or even the web.xml).
Resources
Introduction to Build Profiles
9.3. Resource Filtering

Have defaults in your WAR file corresponding to the production setting, but allow them to be overriden externally e.g. through system properties or JNDI.
String uploadLocation = System.getProperty("upload.location", "c:/dev");
(untested)

Using a properties file isn't too difficult and is a little more readable the web.xml
InputStream ldapConfig = getClass().getResourceAsStream(
"/ldap-jndi.properties");
Properties env = new Properties();
try {
env.load(ldapConfig);
} finally {
if (ldapConfig != null) {
ldapConfig.close();
}
}