Ready made beans to connect MySQL by jdbc? - java

Can I just load com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource class as a bean in Spring? What are this class API? Where it can be found?
I can only find samples of JNDI usage.
Are there any ready-made beans to have such properties like driverName, connectionString userName, password and which allow to issue SQL statements?
EDIT 1
Sorry forgot to say that I need solution except with DriverManagerDataSource because it is said manual it is very basic and not suitable for J2EE containers.

Section 13.3.1 of the Spring User Guide, titled Data access with JDBC, shows how to create a bean to access a database. You specify username, password, driver class, url, etc., to create a bean representing a DataSource.
You can use any data source class here, not only the DriverManagerDataSource shown in the example at the link above. For example, we deploy to Tomcat so I use org.apache.tomcat.jdbc.pool.DataSource as our data source. If you're using Tomcat you can read more about that pool here: The Tomcat JDBC Connection Pool

Related

Difference between connecting to a database using DriverManager and SpringBoot(Hibernate)

There are 2 ways to connect to a database when developing Java apps.
Using DriverManager
Connection conn = DriverManager.getConnection(url, name, password);
// execute the query.
Using application property file in SpringBoot
spring.jpa.hibernate.ddl-auto=none
spring.datasource.url=jdbc:mysql://localhost:5432/db_name
spring.datasource.username=user
spring.datasource.password=password
Now you can use #Entity annotation on your class to put data into database.
My question is how are these 2 ways different. If not how, is SpringBoot method working same as DriverManager in the background.
I assume that by Driver Manager you wanted to made reference to JDBC and by Springboot(Hibernate) you wanted to say JPA.
To simply answer your question, both JDBC and JPA will connect to the driver. Just that if you use JPA this step is made by default without you explicitly coding it.
You can look at JPA as an upper layer of JDBC which handles all the boilerplate code like connecting to the driver.
You can read more about JPA and JDBC here: JPA or JDBC, how are they different?
When you set configuration properties you are just saying to spring: "Hey, i have this properties, can you autoconfigure what i need?". At this point spring at the start of application will use you configuration properties to setup everything you need to connect to your database (using DriverManager or not is not important).
Spring do exactly what you should to do to configure your database connection.
Remember that in 99% of cases you can't write better code than spring do. So, use spring properties

Dynamic datasource config in wildfly

I have a wildfly 10 (Java + Spring) project. I have a requirement to dynamically inject the datasource (mysql) config details to wildfly. But since wildfly depends on the standalone xml file at startup, and needs it before even the java beans are created, the only way I've found so far is to inject is by setting env vars (by running some other program/script to fetch the configs before wildfly starts). Is there any other better option?
Is it possible to do this through the same java application itself, ignoring the xml and set the right config? If yes, how?
DataSource object via JNDI
Externalize your JDBC connection details by using JNDI to access a naming/directory server to obtain an object implementing the DataSource interface.
With a DataSource object in hand, call getConnection to obtain a Connection.
See tutorial by Oracle, Connecting with DataSource Objects.

Choose JDBC database depends on logged user

I have a simple spring boot application. I am using JDBC connection configured by JDBC Template (JDBC url is got from properties file).
Can you tell me how to reach following thing:
JDBC Connection should be established in depends on logged user, I have a problem with projecting in spring such flow of control that object jdbc template will be created after loggining user.
It is about different users use different database.
Can you help me, please?
You can do the routing at the datasource level.
See https://spring.io/blog/2007/01/23/dynamic-datasource-routing/
And
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.html

Some confusion surrounding JDBC Resources and JDBC Connection pools Glassfish

I am about to make a connection to my database and I am using EJB and JPA. I have recently started doing these technologies so I have some problems understand it all at this point:)
I know that the persistence.xml is needed in order to use JPA. It is the file where I configure how to connect to the database, that I know. However it seems like there are multiple ways of doing it.
What would be the difference (or when should I even use the one alternative over the other?) of defining properties such as username, database, password etc. in the persistence.xml file and in Glassfish? Advantages/disadvantages if any.
Underneath on the image I posted I have JDBC Resources and JDBC Connection Pools. I am a litte confused about the terminology of the two. Why don't we add properties such as username, database, password and so on in the JDBC Resources? Could someone explain the difference between them and what they mean?
JDBC Resources
A JDBC resource (data source) provides applications with a means of
connecting to a database. Typically, the administrator creates a JDBC
resource for each database accessed by the applications deployed in a
domain. (However, more than one JDBC resource can be created for a
database.)
http://download.oracle.com/docs/cd/E19316-01/820-4335/ablih/index.html
I think it strange that we add such properties on the pool but not in the resource, but I probably misunderstand the concepts.
In the "JDBC connection pools" you can create container managed JDBC data sources (with connection pooling capabilities). The data source needs to know about at least the JDBC driver, the JDBC URL, username and password.
In the "JDBC resources" you can bind those container managed JDBC data sources to one or more JNDI names so that they are by JNDI available to the deployed web application.
In the persistence.xml you can specify whether to use a local data source or to use a container managed data source. If you want to use a container managed data source, then you should specify its JNDI name. Using a container managed data source has the advantage that you can share a single data source among multiple web applications. In case of JPA, it has also the advantage that you can make use of JTA (container managed transactions) so that you don't need to call transaction.begin(), commit(), rollback() etc in every method.

Hibernate database password at runtime

Is there a way to ask for the database password at runtime instead of putting it (encrypted or not) in the hibernate.cfg.xml file?
Just about every configuration option in Hibernate has a corresponding method on the object being configured. In reality, the configuration is really just a way to bind XML to the objects being set up. See this article for more information: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html
That said, the onus is on you to collect the password at startup. That can be the most difficult part of the problem. Once you've collected the password, send it to the appropriate property.
Usually the best way to do it, if you're using a Java EE app server, is to use a JNDI look up to get the database connection instead of using a driver manager. That way the person who sets up the JNDI connection pool is the only one that has to know the password, and it's generally encrypted in the admin console so it's safe.
I think if you are using programmatic instantiation of the Hibernate configuration, you can initialize it from the configuration file that does not contain a password, set the additional property for the database connection on the configuration object you're instantiating, then call buildConfguration().

Categories