I'm about to begin my first project with java
Let me tell how I used to handle these things...
So far now, I've been workin on asp with a com+ componente made with VB6.
The component is registered via the com+ administration console with a domain user, something lile my_company_domain\my_app_account
The components reads the configuration from an udl file, configured to access the DB with integrated security.
I invoke the componente from asp with server.createobject, the component runs with the specified domain account, and so every DB access runs with this account...
What I like from this approach is the following:
use of integrated security - no sql users
no need to recompile anything to change db (edit udl file) or domain account (edit com+ component configuration)
pooled connections (as I'm always using the same connection string)
production staff can alter the configuration without leaving the account password on a text file
...
well, what would be the best way to achieve something like this on java???
I've already saw something about Commons-DBCP, is it possible to use integrated security with this???
thanks a lot...
--
added in response to a comment
by integrated security I mean I only have to configure a domain account, and that's it, I use no sql server accounts, just the account under which the VB6 com+ component is run.
Ok, maybe that's not the appropiate term, but I hope you get the idea...
Configure DataSource & ConnectionPool on app-server side.
Obtain DataSource from JNDI environment from your web-application.
Related
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
For a long time in many IT services, I see some complex process to manage Java EE application configuration depending of the environments:
- custom tools, with Database or not, to manage replacement in the properties file (unzip war, replace, zip war...)
- Externalize properties file in obscure directory in the server (and some process to update it some time) and some time with a JNDI configuration...
- maven profile and lot of big properties files
But for database connection everybody use jndi datasource.
Why this is not generalized for all configurations that depend of environment ?
Update : I want deal with other variable than datasource, there is no question about datasource : it's in configured in JNDI for Java EE application. After if you want hack JNDI...
Setting up database connectivity (like user name, password, URL, driver etc.) somewhere in the application server has several advantages over doing it yourself in the WAR:
The app server can be a central point where the DB is configured, and you might have several WARs running on that server sharing a DB. So you need to set it up only once.
The DB settings, especially the credentials (username, password) are stored somewhere in the app server instead of somewhere in the WAR. That can have security implications (for instance, restricting access to that file is easier done than in a WAR archive).
You can set up one JNDI path to retrieve a DataSource instance pointing to the DB and do not need to worry about username and password anymore. If you have multiple app servers (one live system, one test system, several developer machines) with different DB URLs and credentials, then you can just configure that in each app server individually and deploy the WAR files without the need to change DB settings (see below).
The server might provide additional services, like connection pools, container managed transactions, etc. So again, you don't have to do it on your own in the WAR.
This is true for other services provided by the app server as well, for example JavaMail.
There are other cases where it you want to configure something that is specific to one web application and does not rely on the environment (the app server), like logging (although that may be set up in the app server, too). In those cases you might prefer using static config files, for instance log4j.properties.
I want to illustrate the third bullet point a bit further ...
Suppose you have one WAR in three app servers (developer machine, test server, live server).
Option 1 (DB setup in WAR)
Create a database.properties :
db.url=jdbc:mysql://localhost:3306/localdb
db.user=myusername
db.pass=mysecretpassword
#db.url=jdbc:mysql://10.1.2.3:3306/testdb
#db.user=myusername
#db.pass=mysecretpassword
#db.url=jdbc:mysql://10.2.3.4:3306/livedb
#db.user=myusername
#db.pass=mysecretpassword
Before you deploy it somewhere, you need to check if your settings are pointing to the right DB!
Also, if you check this file in to some version control system, then you might not want to publish your DB username/password to your local machine.
Option 2 (DB setup in App Server)
Imagine you have configured the three servers with their individual DB settings, and each of them registers the DB with the JNDI path java:database/mydb.
Then you can retrieve the DataSource like so:
Context context = new InitialContext();
DataSource dataSource = (DataSource) context.lookup("java:database/mydb");
This is working on every app server instance and you can deploy your WAR without the need to modify anything.
Conclusion
By moving the configuration to the app server you'll have the advantage of separating settings depending on the environment from your app code. I would prefer this whenever you have settings involving IP addresses, credentials, etc.
Using a static .properties file on the other hand is simpler to manage. I would prefer this option when dealing with settings that have no dependencies to the environment or are app specific.
I have multiple domains in a glassfish 3 server. I am able to login to different domains using glassfish admin console and I want to create jdbc resource/connection pool for a particular domain (say domain2). I know, I can create it using admin console. But I want to do it through CLI. I checked the format of create-jdbc-connection-pool and create-jdbc-resource commands. It does not take any parameter where I can specify the domain name.
Can somebody tell me how to do this using CLI.
Thanks in advance.
The resources are stored within the domain, so you implicitly define the domain when logging in. If you login to domain2, the resources are created in domain2. You can further define the target of the resource by using --target clause on each create-blah command. The target would be a server or a cluster within the domain you have logged in and issue the command against.
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.
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().