0

Is there any difference between declaring The DataSource in META-IF/context.xml file and get it from the spring bean using the JNDI lookup (Approach 1), Or just declaring the DataSource directly via Spring (Approach 2) like :

@Bean(destroyMethod = "close")
DataSource dataSource(Environment env) {
    HikariConfig dataSourceConfig = new HikariConfig();
    dataSourceConfig.setDriverClassName(env.getRequiredProperty(PROPERTY_NAME_DB_DRIVER_CLASS));
    dataSourceConfig.setJdbcUrl(env.getRequiredProperty(PROPERTY_NAME_DB_URL));
    dataSourceConfig.setUsername(env.getRequiredProperty(PROPERTY_NAME_DB_USER));
    dataSourceConfig.setPassword(env.getRequiredProperty(PROPERTY_NAME_DB_PASSWORD));

    return new HikariDataSource(dataSourceConfig);
}

I think the second approach is better because is not tied to a specefic Server, that means if we use the first approach and one day migrate to another Server we must adapt the strategie of the context file in the second server (not true ?).

Thanks

Jiri Tousek
  • 12,211
  • 5
  • 29
  • 43
Sayros
  • 95
  • 3
  • 14

2 Answers2

1

Some points for the first approach (JNDI lookup of DataSource defined in container):

  • Can be configured without touching the actual application
  • It is possible to secure the sensitive information (like password) better
  • DataSource may be shared between many applications on the same server

I use the first approach for security (or "security") reasons when required - often, the customer's requirement is that the password for DB access must not be stored in the application in plain text. A possible response to this is to simply not store the password in your application at all and instead leave it to the customer to provide the DataSource through JNDI.

This makes sense from system administration point of view as well - if the data source ever needs to be reconfigured, it will likely be due to some infrastructure or network change, so it should be in the administrator's power (and also their responsibility) to reconfigure the data source as well. The servlet container should be such place.

If I don't need any of the above, I use the second approach (less complicated, easier to deploy).

Jiri Tousek
  • 12,211
  • 5
  • 29
  • 43
1

If there are multiple applications that use your database. Instead of having each application manage its database configuration, we can configure the DataSource inside container and We will let the applications point to that shared configuration. This will also help you in sharing Db connection pool across all applications.

Pardon, I have just search found similar Answer in SO (otherwise I would not have posted this answer)

JNDI really shines when you have to move an application between environments: development to integration to test to production. If you configure each app server to use the same JNDI name, you can have different databases in each environment and not have to change your code. You just pick up the WAR file and drop it in the new environment.

Here are some other assumptions that are crucial to know when judging this answer:

I don't have access to the servers on which the code is deployed at all, except for read-only access to logs. The person who writes and packages the code is not the same person who configures and manages the server. Once a WAR file starts on its journey to PROD it cannot be changed again without going back to the beginning. Any testing that's done by QA on the test server must be re-done if the WAR is altered. Perhaps you don't see this benefit because you're a lone developer who writes code on a local desktop and deploys right to production.

Source: Why use JNDI

Community
  • 1
  • 1
Pragnani
  • 20,075
  • 6
  • 49
  • 74