I am working on a Java application using Hibernate.
I would like to deploy it on Elastic Beanstalk (Amazon Web Services) to be able to scale accordingly.
RDS is the database I want to use.
However, I do not know how to give my configuration settings to Elastic Beanstalk. Apparently it is now possible, without having to create an AMI and to use this AMI for each new server (when autoscaling).
I use :
hibernate.cfg.xml
server.xml (link to hibernate.cfg.xml)
But I want to scale easily, so no "manual configuration of EC2 instance" to input those files.
So how can I give those settings to my application without the two files ?
How to deploy on Elastic Beanstalk with those info ?
Amazon Relational Database Service (RDS) is a web service to setup relational databases in the cloud. RDS supports relational database engines such as MySQL, Oracle, SqlServer. For MySQL change the hibernate.cfg.xml like below
<session-factory>
<property name="dialect">org.hibernate.dialect.MySQLInnoDBDialect</property>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property
name="connection.url">jdbc:mysql://my_sports_entertainment_db_url/news</property>
<property name="connection.username">my_username</property>
<property name="connection.password">my_password</property>
</session-factory>
Also check How to 'switch' from MySQL to Amazon RDS with minimal application impact?
I can see a way to do this, but it isn't pretty.
Your instance configuration file can include container commands. These run after the container and application are installed, but before the application is started. At this point, it is possible to edit the Tomcat context.xml file to add a datasource. The text you need to add is the usual datasource configuration. Your problem is that you have to do it from a script. The easiest thing might be to write the configuration and deliver it with your application, then use a container command to apply the mighty sed to splice it into the context.xml.
You have another problem in that the actual configuration you need to write must include things like the hostname, username, and password for RDS, which you won't have during development. AWS does expose these to Java through system properties, so the information must be on the machine somewhere. If you could find it, you could mix it into the configuration when you splice it into the context.xml.
Whilst this may be possible, as i said, it isn't pretty. It feels like a hack. There must be a better way of doing this.
Related
While developing a springboot-liquibase application following this I need to specify the database username + password as liquibase.user and liquibase.password in the application.properties file. I am looking for a better secure way to use these parameter (dynamically fetched from some other place and use inside my java code)
Is there a way to achieve this?
There are couple of things you can do:
You can encrypt you properties file using jasypt-spring-boot. For more details have a look at demo app
If you are developing distributed system, then spring-cloud-config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
I have a web application which is initialised using spring and built using maven.
The various properties are loaded using properties files which are statically present. Since various environments require different values for the same properties, i use maven profiles to load different properties files depending upon the environment at build time.
Ex:- dev.properties for dev environment and prod.properties for production environment.
Now i want to make the build independent of the properties files,
The value of the properties will be fetched from some datasource(zookeeper) during context initialisation.
How to load the properties before the context is initialised?
Spring Cloud Config Zookeeper offers a way to do that. I posted a brief example of use here
Properties is just one of Java class and that Apache Configuration project exactly provides such an abstraction. I just showed you a sample for JDBC, but there is really many other stuff there. Here is a sample how I load properties from DB StoredProcedure:
<jee:jndi-lookup id="dataSource" jndi-name="DS"/>
<bean id="storedProcedureConfiguration" class="com.my.proj.config.StoredProcedureConfiguration"
p:dataSource-ref="dataSource"
p:sqlQuery="pki_props.getProperties"/>
<bean id="propertiesFromDB" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"
p:staticMethod="org.apache.commons.configuration.ConfigurationConverter.getProperties"
p:arguments-ref="storedProcedureConfiguration"/>
<context:property-placeholder properties-ref="propertiesFromDB"/>
So, you can implement your own AbstractConfiguration to load Properties from Zookeeper and inject it to the <context:property-placeholder>.
In the java constructor, simply set a connection to the Zookeeper server and get the needed data using the zookeeper client methods. You can find examples here: http://zookeeper.apache.org/doc/trunk/javaExample.html
It would look like this (but you would have to elaborate this)
public YourConstructor() {
Zookeeper zk = new ZooKeeper(host,...);
zk.getData(...);
}
Recently I started a maven project to build an application for integrating
Spring, JPA, JSF
But in the automatically generated folder structure I can see one file named as
db.properties
and also I have one
persistence.xml
Now my question is that Database connection can be defined in either of these files, Can anybody tell me
1. Which way is better and why ?
2. Why there is db.properties file automatically generated while I already have persistence.xml ?
db.properties file is like messages.properties which is used to define key value pair. And after that we will use keys in expression language. So configurations will only be done in
persistence.xml or dataSource.xml
whichever is preferred choice but the values we will take from db.properties in the form of expression language eg.
driverClassName=com.mysql.jdbc.Driver
this is an entry in your db.properties. and you will use it in persistence.xml as follows.
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${driverClassName}" />
I assume, from the fact that you mention JSF, that you are building a web application for deployment to an application server. I also caveat this question in that I don't know about db.properties or where it comes from.
When deploying to an application server, it is always best to configure your database connections in the container and expose them to the application via JNDI. This allows the container to manage connection pooling and credentials and keeps this information out of your WAR/EAR files. It also ensures that your WAR/EAR files are agnostic to the particular database instance, so can be deployed to a container in any environment without modification.
Therefore, I recommend against configuring your datasource in persistence.xml.
See also Difference between configuring data source in persistence.xml and in spring configuration files which is a similar question- the accepted answer there expresses the solution in more detail.
I have a JAVA webapp which is using DB connection pooling for Tomcat+MySQL config.
I have another JAVA webapp which i want to deploy in the same Tomcat and connect to same MySQL database (even access the data from same tables).
I havent figured out a way how to achieve the same.
Should I have connection pooling context.xml for each of the webapps?
Or should I have a global configuration.
In the first case , I assume there is nothing different that i need to do. Only to deploy the webapp which has its own context.xml.. Please correct me if i'm wrong.
If having a global config is a better solution, how to achieve that. Haven't found any good tutorials about it. What changes in each of webapps need to made , so that it knows that it needs to read the global config.
There's nothing wrong with having a separate context for each webapp unless you want to centrally manage changes to the database (i.e. migrate it to a different DB, change connection parameters). If you think your connection properties will change or you want that flexibility then you can use a JNDI datasource in tomcat and manage it there (google is your friend for that).
I have a set of EJBs and other Java classes which need to be configured differently based on the system environment in which they are deployed: production, test, or lab. The configuration information includes stuff like URLs and database connection information.
We'd like to deploy the same exact product (EAR file) in each environment, and have the code then figure out where it is and what its configuration should be, without having to reach out to each deployment server in each environment to make changes.
What is the best way to configure all these components in a centralized, reliable, easy-to-maintain fashion?
Thanks for your thoughts.
The best, IMHO, is to use JNDI entries.
You may have to recode some parts of your application in order to use theses entries instead of plain vars, but with this setup:
Configuration is server-independant: each vendor provides its own implementation, but spec is a standard.
In a clustered environment, config can be persisted in a cluster-wide JNDI tree (see JBoss)
Configuration can be changed thru webadmin without restarting server.
How database connection pool information is stored / configured depends on the app server vendor. Put other variable stuff in property files on the classpath.
If you are deploying the exact same EAR to three different instances of a certain container than you will have to edit the deployment settings as there is no way that the deployment process could have any idea about which one of your three versions you would like to use at a particular deployment.
Deployment settings should go into JNDI entries as Piere-Yves said above.
If I were you, I would have my deployment-script (Ant?) properly populate the JNDI entries depending upon which environment you are deploying to.