For a typical J2EE web application, the datasource connection settings are stored as part of the application server configuration.
Is there a way to version control these configuration details? I want more control on the datasource and other application server config changes.
What is the standard practice for doing this?
Tracking configuration changes to your application server through version control is a good thing to ask for. However, It does imply that all changes are done via scripting, instead of the administrative web interface. I recommend
http://www.ibm.com/developerworks/java/library/j-ap01139/index.html?ca=drs-
as a good background information article on this topic.
Update: Just recently, part 2 has been published here: http://www.ibm.com/developerworks/java/library/j-ap02109/index.html?ca=drs-
When working with WebSphere we found the best approach was to script the deployment and place the script under version control plus the response files for each of the target environments.
Websphere canbe tricky as the directory structure is a mess of files - often there appears to be duplicates and it's hard to figure which is the magic file you need to backup / restore . The question of how to go about this should not detract from the need to do it. - which is a definite yes.
Our (Spring) apps have a hardcoded jndi name in the spring config file. That way, the same ear can be deployed to dev, qa and prod environments, and you don't have to worry about database connection details.
The app server admins ensure that a datasource is registered against that jndi name, with the connection details as appropriate on each environment.
But how does this let me manage changes to datasource configurations in the application servers. Here's a scenario:
DBAs change the connection password of the database server.
Webspehere/Weblogic administrator makes corresponding changes to server configuration through administrator console.
The above change is not version controlled so there is no clean way of knowing the history of such changes.
The problem is not about how the application should be configured but about how the configuration changes should be version controlled. Perhaps it sounds like an overkill for simple projects but for some projects, controlling changes like these really becomes a problem.
Any time you ask yourself "should X be in version control" the default answer is "yes".
For a more refined answer, ask yourself this: is the file created by a person (like a source file or a document) or is it generated by another program (like an object file or a distribution PDF)?
File that are created, and/or maintained, by a human should be under configuration control.
We are always using version control for our app server settings. It's a tool called WLST (weblogic scripting tool) which is part of the weblogic server distribution. The domain configuration is stored within a Jython script, which can easily be executed via command line and therefore integrates superb with our build tool maven.
Creating a preconfigured running weblogic domain only needs to execute a maven goal. All those annoying problems of misconfigured jdbc connections or wrong jms destination parameters are gone. You will always have a appserver configuration which matches the source code at a given time. You will never need to remember which app server setting must be applied for this specific version of the project you are working on.
I really recommend this.
I also would like to know, if there are similar solutions for other application server available. As far as i know there is a way for glassfish via ant. How this can be achieved for JBoss?
Related
Is there any ability to list/manage WAS Liberty queues besides server xml config? Liberty version does not support WAS admin console with it's MQ managing functionality
WebSphere Liberty was designed to have simple configuration, that can be part of your source artifacts and deployed easily via CI/CD tools. So in general it is rather not recommended to modify running server configuration, rather prepare and deliver new server via your pipeline.
Having said that, you can modify server.xml file, and most of the modification will be integrated into running server without the restart.
You also have adminCenter feature, which will give you simplified web console. That console will allow you to modify server.xml via browser, with editor that knows the correct syntax so you dont have to remember all the tag names. However you will not get 'wizard' like console, that you currently have in traditional WAS server.
My problem is that after every code change I have to build and deploy my Java web application (or at least some parts of it), which takes too much time.
JRebel would do the trick, but my company doesn't have a license for it.
I heard that weblogic's nostage mode can save some time, but how can I configure it?
I've changed my Managed Server's staging mode in the Admin Console, but how can I provide the path to my .wars? Or how can I get this thing work?
Sorry for my lack of knowledge, but I'm pretty new to this topic.
You now configured the default staging mode for new deployments, it would probably be easier to just change this during the individual deployments. If you are using the admin console to deploy it is the section called "Source accessibility".
Basically, in nostage / "I will make the deployment accessible" you tell WebLogic where to find your deployment by passing it a file location - which should be accessible for every targeted server. In the default staging mode (aptly called "stage"), you tell the admin server where to find the files and the admin server copies your files to the managed servers.
Unless your limits are in your bandwidth, I don't think this will save you any time during deployments.
I am about to start working on a JSF application and I am trying to decide on how to set up my production environment.
I enjoy working off my VPS for production instead of my local host. Is there a way to launch a JSF app to my server and then build on it from there? Or is that not going to work because I have to have a compiler to compile the java each time I update?
If that is the case would it make sense to just install a compiler to the server?
This is my first JSF and real java application so if there is some good info on this please lead me there.
I have someone working with me and I was assuming if we both work of the server it would be easiest.
How would this work in a professional environment, or in other words how would a team working for a company set their environment up?
How it generally works is that each team member has a local installation, and deployments up the chain to servers are handled by the systems admin guys on requests, them being provided with an installation package containing the compiled application (a WAR or EAR file), any other files needed, and quite likely a script with database changes, an installation manual, and things like that.
You should never develop directly on a production server. Only deploy stuff there once it's complete, tested, and verified to be in working order, and secured against attacks.
I am developing an web app using java/j2ee as middle ware and Mysql 5.1 as database. I have to deploy it on AWS-EC2 server.
My questions are:
How do I create the build
How do I deploy on ec2 server?
I am using Apache Tomcat-6. Should I use any other server like Apache2 as web-server?
Use WTP to create a Dynamic Web Module project.
Use AWS Toolkit for Eclipse
That's pretty terse, but you'll need so many more details that it's pointless to list them here. Read the docs, then come back with specific questions :)
Whether you need Apache2 in front of Tomcat depends on your requirements. If you need it you'll know it :) Things that you might want to punt off on Apache2:
SSL
Static content
URL rewriting
If you are just planning to do every thing manually. You should read this manual http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/
Basically,
You need to create an AMI instance of platform of your choice. (Win/Unix-based).
Configure it with the software that you need. In your case, Tomcat-6 and MySQL-5.1. Configure them. Set Schema etc.
Upload your WAR file to the instance and deploy to Tomcat-6.
Make sure Tomcat port (8080 or whatever you've configured) is open. You can configure this from AWS console's Security Group setting.
Use the instance's Public DNS to access your app. Public DNS can be found from AWS console.
There are many freely available, pre-configured AMI available. Since your setting is one of the most common one. I am sure you will get one and skip Step#2.
We develop an application which is normally deployed on a single webserver. Now we check how it runs in a clustered environment, as some customers are using clusters.
The problem is the app creates a local configuration (in registry/file) which does not make any sense in a cluster. The config is changed by the application.
Is there a generic way (like an interface) to make a central configuration, so the config(-file) itself is not duplicated on each node when the app in deployed in a cluster? Any other recommended options? (doing it manually with config on network-share/in database/some MBean?)
why generic? It must run on different application-servers (like tomcat, jboss, Webspere, weblogic ...) so we cannot use some server-specific feature.
Thanks.
Easiest way for central configuration is to put it on the file system. This way you can mount the file system to your OS and make it available to your app server no matter what the brand or version.
We do this for some of our applications. Shared libraries and/or properties files that we care about (in our case). We set up either JVM parms or JNDI environment variables (trying to move toward those) so we can look up the path to the mounted drive at runtime and load the data from the files.
Works pretty slick for us.
Now if you are writing information, that's a different story. As then you have to worry about how you are running your cluster (is it highly available only? load-balanced?). Is the app running in both clusters as if it was one app? Or is it running independently on each cluster node? If so, then you might have to worry about concurrent writes. Probably better to go with a database or one of the other solutions as mentioned above.
But if all you are doing is reading configuration, then I would opt for the mounted file system as it is simplest.
You may use a library like Commons Configuration and choose an implementation which is cluster-friendly like JDBC or JNDI.
I would consider JDBC and JDNI first, however if you want your servers to be able to run independantly, I would suggest a file distrubtion system like subversion/git/mercurial i.e. if your central configuration servers is down or unavailable, you don't want production to stop.
A version controlled system provides a history of who made what changes when and controlled releases (and roll back of releases)
One way to avoid the issue of the central server adding another point of failure is to use a databasse server which you already depend on (assuming you have one) on the basis that if its not running, you won't be working anyway.