Develop Reference

How to incremental update Java EE web application?

I have a typical web application deployed in Tomcat. The requirement is to provide incremental update way instead of full-package delivery (a war file) when update the application.
For example, once I finish a bug fix which changed a jar file, an XML file and jpg file. I call these 3 files as a patch. I am supposed to deliver the patch file. Even when customers want to rollback to original version, I have to provider a way to rollback the patch.
All the process is supposed to automatically.
From my perspective, the requirement doesn’t make sense. full-package delivery is easy and reliable way to update a web application, I don’t want to introduce complex and error-prone way to update.
Do you have idea to implement incremental update requirement? Thanks!

When you deploy the .war or .ear, the application server usually unpack it into an internal directory. You can change files in this directory directly, with a finer granularity. However, for changes to take effect consistently, you will need to restart the server.
Your perspective is indeed fully correct. Nowadays, sizes of files don't play a significant role, I don't see the problem with whole updates. Why isn't the customer happy with whole updates?
Note: If what he wants is dynamic updates, i.e. without restarting the server, then this is anyway a complete different problem, and mostly impossible for production systems in java (but doable during development, with solutions like JRebel).

You can create a Java Program that uses Delta-Sync protocol i.e. Only those files need to uploaded which are updated. If you have used Dropbox then you will understand pretty well.
Dropbox uses Delta-Sync protocol to update file and sync data.
Either way for time being you can use Dropbox by installing on your client (mapping to server's WAR folder) and your local machine and share that folder. Then whenever you change the files in your local machine it will automatically upload and sync those CHANGED (PATCH) files to your client's machine.

Temporary Directories in WebLogic 10

Whenever, WL is stopped it doesn't delete its temporary directories .. i.e.
domains/mydomain/servers/myserver/tmp/_WL_TEMP_APP_DOWNLOADS
/domains/mydomain/servers/myserver/tmp/_WL_user/
/domains/mydomain/servers/myserver/stage
and because of this, when we deploy new application, it doesn't deploy some JSP or some classes and it keeps the old version of those files. resulting in lots of business errors + runtime error.
Is it a known issue ? How can we tackle it?

In general WL will cache your deployment and won't redeploy unless it is asked to. But it depends on how you deployed your application and if the server is in production or development mode. See development deployments and production deployments.
One easy fix, go to the /domains/mydomain/servers/myserver/ directory and delete:
tmp
cache
logs
and leave the data and security directory. Then restart. This will force WL to redeploy.
My original answer included a delete of the data directory but as #g-demecki and #j23 point out below, that can mess up an admin server. I believe it is OK to delete the data directory on a managed server.

I never run into such issue in production mode, if you are running in development mode and using auto deploy, please follow best practices documented
You must touch the REDEPLOY file (alter its timestamp) any time you
wish to trigger redeployment of an auto-deployed application. Even if
you modify an application while a server is shut down, you must touch
REDEPLOY to ensure that changes are applied when the server next
starts up.

Redeploy should update the tmp - maybe your timestamps are not ok ?
Stop and start will not refresh tmp as it is still used after restart.
From my experience it is enough to delete tmp when server is down to force unpack WAR (it is a matter of unpacking WAR to tmp by Weblogic, this is the main task done during deployment).
e.g. in your case
/domains/mydomain/servers/myserver/tmp/

In my case, a simple reboot of the Linux machine fixed the issue.

Tomcat taking too much time to start

I am currently using tomcat 6 as my Web Server. I have a very small application which should not take long to deploy on server, but my tomcat is taking too long start.
It is taking most of its time in following step.
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
I don't know why it is taking much time. Same is the case with stopping the server. I tried almost everything I know. I also tried to delete server from the workspace and started from scratch. I don't know what is the problem.

You can find out which library consumes the time. When the server is being started in a debug mode, pause its thread several times and examine stacktraces. There may be possibly some library that populates its Spring application context, weaves advised objects, initializes file storage, whatever. If so, you will see it from stacktraces.

Have you removed all the default web applications that comes with the tomcat installation ?
Even though your webapp is a small one, there might be other applications that are taking time to be installed. You can check this from the server log files with the name catalina___.log files.

I know this post is old, even i wanted to share few check points on this because these are irrespective of tomcat version...
I was facing the same issue and i followed below steps and now my server is starting with in 130 ms.
First verify the console if you are using any IDE, there you can find time in milliseconds for each application. So you will come to know which one is taking long time.
To make sure, your finding is correct just remove that app from 'webapps' folder and start tomcat again.
Remove the default applications which you don't need. Usually we only use tomcat manager, so just keep manager app and remove other applications from 'webapps' folder
Make sure 'temp' folder is empty
Clean up the older log files. And don't write your application log files in server folder.
Start the server first and deploy the file later. So that you don't face timeout error.
This is what i tried any succeed.

Possibly this is due to a lack of availability of random entropy, which Tomcat requires.
See https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource
and
Slow startup on Tomcat 7.0.57 because of SecureRandom
(Edit: first link updated)

I guess you have placed all your libraries (JARs) in the WEB-INF/lib folder. Instead move those to a separate directory and refer the directory or JARs using shared.loader in the catalina.properties

Why does Java Web Start redownload jars from JBoss?

We just discovered that every time we restart JBoss, all of our Java Web Start clients redownload all of their jars, instead of reusing the cached jars, even if our application has not changed.
From what I've seen on the web, Java Web Start does an HTTP HEAD to decide whether or not to download a jar. So I ran HTTP HEAD on all jars in our application, and discovered that after restarting JBoss, the modified time of all the jars has changed!
Why is this, and how can I fix it? The jars inside of my application archives have not changed at all. As near as I can tell, JBoss uses the time of startup or time of deploy as the modified time. This is going to completely short-circuit Java Web Start's ability to use cached jars from previous runs, if I understand correctly.
We use JBoss 6, if that's an issue. Previously we used JBoss 4. I want to check to see if we had the problem under JBoss 4, but we now have so many dependencies on the newer JBoss that it is going to take some work to make that test happen.

Try deploying your application as an exploded web application instead of a WAR file.
That would prevent JBoss having to decompress the application and potentially mess up the modification dates.
You'll have to handle updates to your app in a way that preserves modification dates, e.g., rsync, but that might be easier than downgrading or patching JBoss.

It looks like VFSUtils isn't maintaining the lastModifiedDate of the file when it mounts the filesystem to the tmp directory on server startup. You could patch the copy methods in that class to try to set the timestamp of the new file based on the values from the physical file.
As a response to the comment by chubbard: the problem does not occur with Tomcat (tomcat 7.0.21 to be precise).

There is an issue (https://issues.jboss.org/browse/JBVFS-177) created about the VFSUtils.unzip() which does not preserve timestamps while deploying (still applicable to JBoss 6.1).
As the issue is related to the unzip method the solution of blahdiblah may indeed works.
Another way would be to use Java Web Start with a version based (Modification of the jnlp with versionEnabled and creation of a version.xml).

Loading a class file immediately AFTER startup [duplicate]

This question already has an answer here:
Using special auto start servlet to initialize on startup and share application data
(1 answer)
Closed 7 years ago.
We have a few war files deployed inside an ear file. Some of the war files have a class that caches static data from our PLM system in singletons. Since some of the classes take several minutes to load we use the load-on-startup in the web.xml to load them ahead of time. This all works fine until we attempt to re-deploy the application on our production servers. (WebLogic 10.3) We get an exception from our PLM API about a dll already being loaded. Our PLM vendor has confirmed that this is a problem and stated that they don't support using the load-on-startup. This is also a huge problem on our development boxes where we have redeploy the app all the time. Most of us, when we're not working on one of the apps that uses a cache, have them commented out. Obviously we can't do that for the production servers. Right now we transfer the ear to the production server, deploy it in the console, wait for it to crash, shut the app server instance down and then start it up again.
We need to find a way around this...
One suggestion was to create a servlet that we can call after the server boots that will load the various caches. While this will work I'm looking for something a bit cleaner. Is there anyway to detect once the server started and then fire off the methods?
Thanks.

We had a similar problem with a third party JDBC driver that loaded a native DLL. When redeploying the app the driver would crash saying the DLL was already loaded. The solution (if one can call it that) was to move the driver from deploy into lib. This way the driver was global to the app server and didn't need to be reloaded when the app was redeployed.

What about using a servlet container lifecycle listener, such as ServletContextListener?
Example on how to use.
EDIT: Sorry, after re-reading your question I don't think this will work. You want something that will load only once per server life, not application life. The ServletContextListener's methods will be called each time the app is deployed, just like a load-on-startup servlet (which it seems you are using). My suggestion will do the exact same thing in a different way.
I would try Chris Nava's suggestion.
EDIT2: It looks like tomcat has some lifecycle listener(s) available to it also. It looks like documentation is sparse, but this potentially would allow you to do something on server startup specifically only once.
EDIT3: Yes, a tomcat lifecycle listener is the way to go. This link explains pretty well how to set one up. Should be fairly straight forward. If you ignore the part about adding the Transaction to tomcat, it goes over pretty thoroughly how to add a lifecycle listener.